Re: linux-kernel-digest V1 #188

Alan Cox (alan@cymru.net)
Wed, 18 Oct 1995 00:00:27 +0100 (BST)


> From: Zefram <A.Main@dcs.warwick.ac.uk>
> Date: Tue, 10 Oct 1995 22:37:14 +0100 (BST)
> Subject: Re: extended partitions
>
> Personally, I favour a kernel-generated /dev, for two major reasons.
> Firstly, it makes standardisation of device names easier, and enforces
> that standardisation more widely. Secondly, it avoids the terrible

Great - principle one of what makes unix great

-- IMPLEMENTATION _NOT_ POLICY BELONGS IN THE KERNEL

> clutter that tends to accumulate in /dev by having only supported
> devices represented, and also avoids the problems that occur when a
> supported device has no node in the filesystem.

Some of us happen to like having non standard /dev. Not least of which
because the normal /dev is broken and has stuff like /dev/ttyS15 not
/dev/ttySf in it.

> the standard kernel, someone -- possibly me -- will write a devfs
> module for userfs. It would be feasible to have a stripped-down

That is the right approach - thats your own policy option and doesn't annoy
the rest of us.

On another subject

> > The feature that was definitely the most helpful was crash dumps. Often

> I've been screaming for this for a while; but every time I've brought it up,
> it's been shot down... reasons given:
>
> 3) It's never likely to work. If the kernel crashes and you try to dump
> to disk, you will most certainly format your hard drive etc. etc.
> (ok fine. if that's the way you want to play, we'll dump to
> FLOPPY DISK. Take that!)

Fine. Actually if you want to dump your system usefully on a crash get
remote kernel debugging working. When you can crash in an interrupt handler
view the source line, fix the wrong pointer and continue then you'll
understand what being able to source level debug your kernel buys you -
and almost all the bits you need, all the hard stuff is already in
gdb now.

Alan