Very Computer

Quote:> As a side note, this thing is so tiny (less than 4K on sparc64!) so
> why don't we just include it unconditionally instead of having all
> of this "turn it on for these drivers" stuff?

What I'd much rather see if this is an issue is:

bool    'Do you want to customise for a very small system'

which auto enables all the random small stuff if you say no, and goes
much deeper into options if you say yes.

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

        Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

   > As a side note, this thing is so tiny (less than 4K on sparc64!) so
   > why don't we just include it unconditionally instead of having all
   > of this "turn it on for these drivers" stuff?

   Because 100 4K drivers suddenly becomes 0.5Mb.

However this isn't a driver, the crc library stuff is more akin to
"strlen()".  Are you suggesting to provide a CONFIG_STRINGOPS=n
too?  I wish you luck building that kernel :-)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quote:>    Because 100 4K drivers suddenly becomes 0.5Mb.

> However this isn't a driver, the crc library stuff is more akin to
> "strlen()".  Are you suggesting to provide a CONFIG_STRINGOPS=n
> too?  I wish you luck building that kernel :-)

"Gee making this link is hard" is not a good reason to simplify the
config file, its a good reason to simplify the make file system
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

The Config.in for crc32 only exists for the case where no driver in the
built kernel uses it... but a 3rd party module might want it.

        Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quote:

>    tristate_orif "blah" CONFIG_FOO $CONFIG_SMALL

> This doesn't solve the CRC32 case.  What if you want
> CONFIG_SMALL, yet some net driver that needs the crc32
> routines?

It *does* mean the configure rules need to contain these dependencies,
though.

crc32 is an interesting case... you can create code to make the tables
with a very small amount of code.  This saves space on disk, but not
in memory; in fact, if you can't jettison this code you lose in
memory...

        -hpa
--

"Unix gives you enough rope to shoot yourself in the foot."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

   Maybe not in this hypothetical future situation, but currently makefile
   magic was added for crc32 specifically to ensure that it is linked
   in when needed... even when CONFIG_CRC32=n.

   The Config.in for crc32 only exists for the case where no driver in the
   built kernel uses it... but a 3rd party module might want it.

My point is this: Having to say something like "CONFIG_INEED_CRC32"
for each driver that needs it is just plain stupid and a total eye
sore.

It would be really great if, some day, you just add your source
file(s) to drivers/net and that is the only thing you ever touch.  You
DO NOT touch Makefiles, you DO NOT touch Config.in files, you DO NOT
add Config.help entries.

The Makefile rules are auto-generated from keys in the *.c file(s), as
are the Config.in and help entries.  Ie. cp driver.[ch]
linux/drivers/net and then simply rebuild the tree.

Think of what kind of pains this would save from a maintainership
point of view.  When multiple new drivers are added at once we run
into all kinds of conflict issues today, whereas my scheme would do
away with that for all cases except totally new subsystems. (but I
think that could be automated in a similar fashion as well)

I have this feeling Keith Owens is going to scream "the new build
system DOES EXACTLY THAT!"  If so, that's fscking great. :-)

That is the kind of direction I'd like to see things going in.  The
lib config thing checking "if LANCE or 8130TOO or ... then force CRC32
on", on the other hand, is just garbage.  It is rediculious to expect
J. Random driver author to know to put junk into weird places like
that just to get at the crc32 routines.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Look at how crc32 is -really- included in the kernel.

        Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

        Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

   As long as Makefiles control initialization order, you need monolithic
   Makefiles.

With the current 2.5.x scheme, you can put your init into the
appropriate group.  Makefiles only control init order within
the groups.

I actually like this solution a lot.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quote:>If you have a dependency concern, you put yourself in the
>right initcall group.  You don't depend ever on the order within the
>group, thats the whole idea.  You can't depend on that, so you must
>group things correctly.

The Makefiles still control order within the .text.init section
(__init, module_init).  Many drivers depend on the Makefile getting
that order correct, otherwise probes stuff up.  But which entries are
order sensitive and which ones are from a developer picking a random
place to insert obj-$(CONFIG) is anyone's guess.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quote:>  heh, after I've read that you managed to boot 2.4 + rmap in a machine
> with just 4 MB after tweaking some table sizes I thought about
> devoting some time to identify those tables and making them options in
> make *config, with even a nice CONFIG_TINY, like you said 8)
> I'll eventually do this, and I'd appreciate if people send me
> suggestions of tables/data structures that can be trimmed/reduced.
> Yeah, I'll take a look at the .config files used in the embedded
> distros.

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

   On Fri, 01 Feb 2002 11:07:42 +0100,

   >libc.a was invented precisely to handle such stuff automatically when
   >linking... if it doesn't work, it should be fixed. I.e., making .a --> .o
   >is a step in the wrong direction IMVHO.

   There are two contradictory requirements.  crc32.o must only be linked
   if anything in the kernel needs it, linker puts crc32.o after the code
   that uses it.  crc32.o must be linked before anything that uses it so
   the crc32 __init code can initialize first.

Horst isn't even talking about the initcall issues, he's talking about
how linking with libc works in that it only brings in the routines you
actually reference.

Will you get over the initcall thing already, you must be dreaming
about it at this point. I mean really, just GET OVER IT. :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

        Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quote:> If you have a dependency concern, you put yourself in the
> right initcall group.  You don't depend ever on the order within the
> group, thats the whole idea.  You can't depend on that, so you must
> group things correctly.

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/