public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nicholas Knight <nknight@pocketinet.com>
To: Keith Owens <kaos@ocs.com.au>, "Albert D. Cahalan" <acahalan@cs.uml.edu>
Cc: timothy.covell@ashavan.org,
	adriankok2000@yahoo.com.hk (adrian kok),
	linux-kernel@vger.kernel.org
Subject: Re: system.map
Date: Wed, 2 Jan 2002 14:09:53 -0800	[thread overview]
Message-ID: <WHITEAiPyTxQplr0tEj00000aaa@white.pocketinet.com> (raw)
In-Reply-To: <10236.1010007095@ocs3.intra.ocs.com.au>
In-Reply-To: <10236.1010007095@ocs3.intra.ocs.com.au>

On Wednesday 02 January 2002 01:31 pm, Keith Owens wrote:
> On Wed, 2 Jan 2002 16:17:30 -0500 (EST),
>
> "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.
>
> System.map is not required for booting, it is only used after init
> starts, therefore it does not belong in /boot anyway.
>
> 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.
>
> For all those reasons, putting System.map and .config in /boot is the
> wrong thing to do.  There is no point in creating yet another

For what reasons? I see no valid reason for it being the "Wrong" thing 
to do. I wouldn't even call it QUESTIONABLE. Nor is it simply a 
"holdover". There are still systems in use whos BIOS simply *does not 
support* booting past the 1024th cyl.
1. Putting stuff in /boot is generaly the "standard" thing to do, 
generaly won't cause confusion among experienced users, and will make 
sense to new users; /lib/modules/* will make no sense whatsoever.

2. /boot is shorter than /lib/modules/`uname -r`, and no I'm not 
kidding. I like short pathnames, it's for this reason I prefer to 
deposit stuff in /usr instead of /usr/local when it's on my personal 
desktop system. I'll sometimes spend hours copying kernels around or 
troubleshooting. The last thing I want to do is type 
/lib/mod<tab>/2.4<tab><damn forgot, more than one 2..4 
kernel>.18<tab><damn forgot more than one -pre <pre-1>/bz<tab> when I 
could instead type /bo<tab>/kern<tab>2.4.18....
This of course assumes I'm using a shell with filename completion! That 
in itself is not always possible on an extremely broken system.

3. Given that neither system is inherently bad, what makes you 
qualified to say it's "wrong" ?

> directory to hold these files when /lib/modules/`uname -r` will do
> the job.  Even on systems with no modules, /lib/modules can be
> created to hold the kernel specific files.  I put my bootable kernels
> in /lib/modules as well, then I have exactly one place to remove to
> get rid of an old kernel.
>
> 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.
>
> >It's a wee bit slower too.
>
> ????

  reply	other threads:[~2002-01-02 22:10 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-02 19:11 system.map adrian kok
2002-01-02 19:26 ` system.map Timothy Covell
2002-01-02 19:39   ` system.map Tony Hoyle
2002-01-02 20:03     ` system.map Timothy Covell
2002-01-02 20:19       ` system.map Kilobug
2002-01-02 20:35         ` system.map Timothy Covell
2002-01-02 21:14           ` system.map Eric S. Johnson
2002-01-03  9:43           ` system.map Miquel van Smoorenburg
     [not found]             ` <02010312301401.01898@manta>
2002-01-03 10:59               ` Sync and reboot (was: Re: system.map) Miquel van Smoorenburg
2002-01-03 11:17                 ` Andre Hedrick
2002-01-02 20:25       ` system.map Tony Hoyle
2002-01-02 20:45         ` system.map Timothy Covell
2002-01-02 21:10           ` system.map Alan Cox
2002-01-02 23:07       ` system.map Nicholas Harring
2002-01-03  2:14     ` system.map Daniel Phillips
2002-01-03 15:54       ` system.map Albert D. Cahalan
2002-01-02 19:47   ` How can one get System.map w/o vmlinux? Timothy Covell
2002-01-02 20:34     ` David Golden
2002-01-02 22:00     ` Christian Koenig
2002-01-02 19:51   ` system.map Horst von Brand
2002-01-02 20:54   ` system.map Keith Owens
2002-01-02 21:13     ` system.map Timothy Covell
2002-01-02 23:01       ` system.map skidley
2002-01-02 23:14         ` system.map Timothy Covell
2002-01-02 21:17     ` system.map Albert D. Cahalan
2002-01-02 21:31       ` system.map Keith Owens
2002-01-02 22:09         ` Nicholas Knight [this message]
2002-03-09  0:21           ` system.map H. Peter Anvin
2002-01-02 22:23         ` system.map Albert D. Cahalan
2002-01-02 23:38           ` system.map Marcel J.E. Mol
2002-01-02 19:30 ` system.map Sebastian Roth
2002-01-02 21:25   ` system.map Lionel Bouton
2002-01-02 22:15     ` system.map David Golden
2002-01-02 22:21       ` system.map Nick LeRoy
2002-01-02 22:29       ` system.map Lionel Bouton
     [not found] <fa.ephh22v.1ljqarg@ifi.uio.no>
     [not found] ` <fa.hmqrtsv.13jqup8@ifi.uio.no>
2002-01-02 21:14   ` system.map John Weber
2002-01-02 21:42     ` system.map Keith Owens
  -- strict thread matches above, loose matches on Subject: below --
2004-12-06 17:34 System.map Anoop T
2004-12-07 11:43 ` System.map Jan Engelhardt
2005-07-12 16:34 system.map vacant2005
2005-07-13 10:21 ` system.map Jan Engelhardt
     [not found]   ` <200507131244.08336.vacant2005@o2.pl>
2005-07-13 10:45     ` system.map Jacek Jabłoński
2005-07-13 10:56   ` system.map Arjan van de Ven
2005-07-13 11:04     ` system.map Jan Engelhardt
2005-07-13 11:27       ` system.map Russell King
2005-07-13 11:33       ` system.map Arjan van de Ven
2007-10-14 17:07 System.map Philip
2007-10-14 18:45 ` System.map Jan Engelhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=WHITEAiPyTxQplr0tEj00000aaa@white.pocketinet.com \
    --to=nknight@pocketinet.com \
    --cc=acahalan@cs.uml.edu \
    --cc=adriankok2000@yahoo.com.hk \
    --cc=kaos@ocs.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=timothy.covell@ashavan.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox