Keith Owens writes:
> "Albert D. Cahalan" <acahalan@cs.uml.edu> wrote:
>> That's not a nice place. Besides the fact that System.map is
>> neither library nor module, /lib/modules is less likely to
>> exist than /boot is. It's a wee bit slower too.
>
> /boot is a hangover from old i386 systems that could not boot past
> cylinder 1024 so you needed a special partition to hold the boot
> images. That restriction does not exist on any system less than 5
> years old nor on most non-i386 machines, the requirement for a special
> /boot is obsolete on most machines.
Who said anything about being special? I have a Mac with kernels
in /boot. It boots via OpenFirmware loading yaboot from an HFS
partition, then yaboot reading the ext2 root partition.
I suppose a separate boot partition would be good if I were to
use a Reiserfs root partition. I might as well mount this boot
partition on /boot and put all my kernels there, instead of
mounting it on /lib/modules.
> System.map is not required for booting, it is only used after init
> starts, therefore it does not belong in /boot anyway.
It's not about modules either. :-) If you can ignore the
name, I can too. So "/boot" means "kernel stuff".
> IA64 requires boot files to be in /boot/efi which must be a VFAT style
> partition. Trust me, you don't want anything in /boot/efi unless you
> have to.
VFAT isn't the fastest, and isn't multi-user, but who cares?
It works perfectly fine for System.map files.
Eh, what goes in /boot that couldn't be on the VFAT partition?
I'm thinking the VFAT partition ought to be mounted at /boot.
> If it makes you feel happier, think of /lib/modules as 'kernel specific
> data'. Pity about the name but it is hard coded into too many programs
> to change it to /lib/kernel or /kernel.
I could agree to use /kernel/2.4.18-pre1/* for all the misc. stuff
and /kernel/2.4.18-pre1/modules/* for the modules. So you add this
to the search path for your stuff, and make the 2.5 install prefer
this location if it exists. Who else would care? Then after all the
distributions have 2.6.xx kernels, drop /lib/modules from the tools.
Killing /boot could wait a bit longer perhaps, or maybe not.
>>It's a wee bit slower too.
>
> ????
2 dirs: / /boot
4 dirs: / /lib /lib/modules /lib/modules/2.4.18-pre1
So an inode and at least one block for each. You lose even
if you figure that / and /lib would be cached already.
Plus /boot comes earlier in the "ps" search path, so you pay
the cost of looking in /boot anyway.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 07 2002 - 21:00:18 EST