Re: devfs

Re: devfs

[beolach]

Sorry for the length of this reply, I was bored and felt like writing a novel.

Well, no you don't *need* to have devfs, and it would be really easy to remove,
but I wouldn't recommend it, for a couple reasons.  First of all, devfs really
is the best way to do what's being done (see below), and secondly (and more
importantly) I don't subscribe to the engineering maxim, "If it's not broken,
fix it."  I've had enough grief from trying to "fix"/improve/whatever stuff
that wasn't broken that I don't recommend making any unnecessary changes to
a system that is currently working.  If you do want to disable devfs, it
should be as simple as passing devfs=nomount at the boot prompt, and possible
editing your startup scripts not to run devfsd.  This is assuming that your
distribution includes a standard set of device files - most do.  And there
might be other pitfalls to avoid that I'm not aware of.

Some history on device files: basically, *nix systems use special files in
the /dev directory to refer to physical devices on the system.  The "old"
(pre-devfs) way for these special files to be created was with the mknod
command.  Because there are at the very least dozens of these special device
files required to opperate correctly, most *nix distributions came with the
most common device files already created.  Generally, the distributions tried
to include every possible device file that could be in the system, so that the
end user would never have to worry about creating them.  This is where the
problem starts.  There are so many possible devices that could potentially be
in any given system that the /dev directory installed by default from most
distribution started to get very cluttered.  For example, hard drives.  Most
home desktop computers only support a max of 4 IDE drives. But, especially on
the servers that *nixes often run on, there could be many more, and often
they would be SCSI drives.  So instead of just having /dev/hd[a-d], Slackware
(my preferred distro) includes /dev/hd[a-t] & /dev/sd[a-h].  And then we have
up to 32 partitions for each IDE hard drive, and 15 for each SCSI drive.  So
here we have 788 special device files just for hard drives & partitions.
Hopefully you can see how this becomes really cluttered with stuff that, for
most systems, is unnecessary.  Just FYI, Slackware comes with over 23000
special device files by default, the majority of which are usually unneeded.

Now assume that you install a new device (say, a rare video card) that needs
a special device file to work properly, but your distribution hadn't included
that particular device file.  Now you need to create it.  If your lucky, the
distribution or the device manufacturor will have supplied a MAKEDEV script
that will do this for you; if you're unlucky you'll need to find out what the
device file is supposed to be named, and what major & minor device numbers it
expects.  Hopefully it's well documented & easy to find, but you could end up
digging through the source code hunting for the major/minor numbers (alright,
that is a unlikely worst case scenario, but it could happen).

Now lets talk about the naming system.  You've already mentioned that this is
one of the big areas of controversy around devfs.  But lets start with the
"old" (pre-devfs) naming system.  The problem here was that the naming system
was overly cryptic and hard to interpret.  Again I will illustrate with disk
drives.  IDE hard drives would have device files like /dev/hda or /dev/hdb;
which at first glance looks simple enough: hd for Hard Drive, and a letter to
differentiate between multiple hard drives.  But wait; /dev/hda could be any
IDE device, like a CD-ROM, Tape, or Floppy drive, not just a hard drive.  And
my hard drive could be SCSI, so it wouldn't be a /dev/hd? device.  It would
be /dev/sda.  And a SCSI CD-ROM drive would be /dev/sr0 (notice it a number
rather than a letter to differ between multiple SCSI CD-ROMS), and a SCSI
tape drive would be either /dev/rst0 or /dev/nrst0 depending on if it was a
rewinding or nonrewinding drive.  Anyway, with the old naming scheme
everything ended up being a jumble of letters and numbers, that supposedly
stand for something (hd=hard drive; sd=SCSI drive), but actually don't; and
if you don't already know what a device name means, good luck guessing.

Devfs is a virtual device filesytems designed to solve these problems.  It
dynamically creates & removes special device files as devices are added or
removed from the system (a major benefit if you deal with hotplug stuff like
USB), or when the drive module is inserted or removed from the kernel.  So
/dev only has the special device files for devices that actually are in the
system - forget the other 20000 or more devices files that I don't need.  And
as long as I can find a driver for this rare video card I just found, it will
work, without me needing to mess with mknod and finding major/minor numbers
(okay, maybe not - some device drivers still don't support devfs, but not
many, and even if it doesn't I'm no worse off than if I wasn't using devfs).
The changes to the naming scheme are, IMO, less important, but are still an
improvement.  And because enough people do dislike the new naming scheme, it
can be changed in /etc/devfsd.conf (if you can figure out how - my very brief
glance at it looked complicated).  While the new names are longer, they also
give more information with less ambiguity than the old names.  And IIRC devfs
by default does make symlinks to to all the old names.  This means that while
on the old system /dev/hdb could be any type of IDE device, on the new system
I can `readlink /dev/hdb` and it will show the new name for the device, which
might be "ide/host0/bus0/target1/lun0/cd" - which tells me this is a CD-ROM
on lun0 (not sure what that is... all I know is most IDE devices only have 1
lun) on the slave channel (target1) of the primary bus (bus0) of the first IDE
controller (host0) in the system.  All of that other than what type of drive
it is can be interpreted from from the old naming system, but this spells it
out better.

Well, that's my novel for today.  Hope you enjoy,
Conway S. Smith
> Hello all,
> I was reading the thread subject=(error message interpretation 
> help?) and the reference to "devfs". I have a stock installation of 
> MDK9.2 and my understanding is that "devfs" is in the kernel or 
> (module maybe?) by default.
> I should say right off the bat that I am a major newbie so bare with 
> me. I've heard complaints about "devfs" before, for one thing the 
> naming convention I noticed on my "df" output alittle long and hard 
> to read for instance.
> 
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/ide/host0/bus0/target0/lun0/part5
>                        380M  115M  246M  32% /
> 
> Someone told me that was because I had "devfs" I did some reading 
> and I think I can change that part on my system with 
> /etc/devfsd.conf but my question is do I really need "devfs" and if 
> not how can I remove it or disable it, and do I need to replace it 
> with something else?
> 
> -- 
> Mike
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

Re: devfs

[mike]

mike wrote:
> beolach@comcast.net wrote:
> 
>> Sorry for the length of this reply, I was bored and felt like writing 
>> a novel.
> 
> 
> Thats quite alright, I need to have things spelled out to me.
> And your explanation helped me understand quite abit more of whats going 
> on.
> 
>> Well, no you don't *need* to have devfs, and it would be really easy 
>> to remove,
>> but I wouldn't recommend it, for a couple reasons.  First of all, 
>> devfs really
>> is the best way to do what's being done (see below), and secondly (and 
>> more
>> importantly) I don't subscribe to the engineering maxim, "If it's not 
>> broken,
>> fix it."
> 
> 
> I agree with you on that, theres much more to it than I thought, and 
>  from your explanation way out of my league. Sounds like it could get 
> complicated. My system runs well for me I would hate to 'jinks'
> that :-)
> 
> 
>>  And because enough people do dislike the new naming scheme, it
>> can be changed in /etc/devfsd.conf (if you can figure out how - my 
>> very brief
>> glance at it looked complicated).  While the new names are longer, 
>> they also
>> give more information with less ambiguity than the old names.  And 
>> IIRC devfs
>> by default does make symlinks to to all the old names.
> 
> 
> I was used to the /dev/hda naming scheme and understood it, is why the 
> new naming kinda through me when I used the "df" command.
> But your explanation of how it works makes sense to me, and I believe I 
> can used to it.
> 
>>
>> Well, that's my novel for today.  Hope you enjoy,
>> Conway S. Smith
> 
> 
> I appreciate your responce thanks, Conway
> 


-- 
Mike


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

devfs

[mike]

Forgot some more info.
ext3 file system
no scsi drives
-- 
Mike


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

devfs

[mike]

Hello all,
I was reading the thread subject=(error message interpretation 
help?) and the reference to "devfs". I have a stock installation of 
MDK9.2 and my understanding is that "devfs" is in the kernel or 
(module maybe?) by default.
I should say right off the bat that I am a major newbie so bare with 
me. I've heard complaints about "devfs" before, for one thing the 
naming convention I noticed on my "df" output alittle long and hard 
to read for instance.

Filesystem            Size  Used Avail Use% Mounted on
/dev/ide/host0/bus0/target0/lun0/part5
                       380M  115M  246M  32% /

Someone told me that was because I had "devfs" I did some reading 
and I think I can change that part on my system with 
/etc/devfsd.conf but my question is do I really need "devfs" and if 
not how can I remove it or disable it, and do I need to replace it 
with something else?

-- 
Mike


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

Re: devfs

[Ken Moffat]

On Mon, 2 Feb 2004, mike wrote:

> Hello all,
> I was reading the thread subject=(error message interpretation
> help?) and the reference to "devfs". I have a stock installation of
> MDK9.2 and my understanding is that "devfs" is in the kernel or
> (module maybe?) by default.
> I should say right off the bat that I am a major newbie so bare with
> me. I've heard complaints about "devfs" before, for one thing the
> naming convention I noticed on my "df" output alittle long and hard
> to read for instance.
>
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/ide/host0/bus0/target0/lun0/part5
>                        380M  115M  246M  32% /
>
> Someone told me that was because I had "devfs" I did some reading
> and I think I can change that part on my system with
> /etc/devfsd.conf but my question is do I really need "devfs" and if
> not how can I remove it or disable it, and do I need to replace it
> with something else?
>
>

Based on past experience with mdk8.2, which used devfs and worked
extremely badly for me, I'd recommend doing without.  However, that's a
lot easier said than done.  You'll need to create static devices, and
you won't be able to do this while devfs is blocking access to the real
underlying /dev, which means booting from a recovery CD as well as
knowing which devices you need, and which groups should own them.

I also take the view that most people don't change their underlying
hardware and peripherals very often, so for me manually adding a device
when I add a usb printer is par for the course.  If you don't want that
level of involvement and you don't have any problems with it, keep it.

Funnily enough, based on an email a little while ago on lkml about udev,
I thought Mandrake had already moved away from devfs.  [ udev
reimplements some of what devfs does, with 2.6 kernels, but its still at
an early stage and certainly not intended as a drop-in replacement. ]

Ken
-- 
Brighton tops UK Jedi league
http://www.theregister.co.uk/content/28/35186.html

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

Re: devfs

[mike]

mike wrote:
> Ken Moffat wrote:
> 
>>
>>
>>
>> Based on past experience with mdk8.2, which used devfs and worked
>> extremely badly for me, I'd recommend doing without.  However, that's a
>> lot easier said than done.  You'll need to create static devices, and
>> you won't be able to do this while devfs is blocking access to the real
>> underlying /dev, which means booting from a recovery CD as well as
>> knowing which devices you need, and which groups should own them.
>>
>> I also take the view that most people don't change their underlying
>> hardware and peripherals very often, so for me manually adding a device
>> when I add a usb printer is par for the course.  If you don't want that
>> level of involvement and you don't have any problems with it, keep it.
> 
> 
> I think I'll keep it, sounds like it does alot for me which I'm not 
> knowledgeable enough to do for myself. At least at this point in my 
> learning process :-)
> 
>> Funnily enough, based on an email a little while ago on lkml about udev,
>> I thought Mandrake had already moved away from devfs.  [ udev
>> reimplements some of what devfs does, with 2.6 kernels, but its still at
>> an early stage and certainly not intended as a drop-in replacement. ]
>>
>> Ken
> 
> 
> Thanks for reply Ken.
> 


-- 
Mike


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

devfs

[Ian Molton]

On 11 Nov 2002 20:50:39 -0500
Robert Love <rml@tech9.net> wrote:

> On Mon, 2002-11-11 at 20:32, Ryan Anderson wrote:
> 
> > From an outsider point of view (and because nobody else responded),
> > I think the big question here would be: Would you use it after this
> > cleanup?
> > 
> > If you say yes, I'd say that's a good sign in its favor.
> 
> Good heuristic, except Al would not use devfs in either case :)

Personally I love devfs. I've not looked at its internals, but its never
failed me yet, and I like the way /dev only contains stuff that actually
exists.

And if Al doesnt like the code... hes free to reimplement it...

Re: devfs

[Xavier Bestel]

Le mar 12/11/2002 à 10:32, Ian Molton a écrit :
> On 11 Nov 2002 20:50:39 -0500
> Robert Love <rml@tech9.net> wrote:
> 
> > On Mon, 2002-11-11 at 20:32, Ryan Anderson wrote:
> > 
> > > From an outsider point of view (and because nobody else responded),
> > > I think the big question here would be: Would you use it after this
> > > cleanup?
> > > 
> > > If you say yes, I'd say that's a good sign in its favor.
> > 
> > Good heuristic, except Al would not use devfs in either case :)
> 
> Personally I love devfs. I've not looked at its internals, but its never
> failed me yet, and I like the way /dev only contains stuff that actually
> exists.

I'm wondering if a totally userspace solution could replace devs ?
Something using hotplug + sysfs and creating directories/nodes as they
appear on the system. This way, the policy (how do I name what) could be
moved out of the kernel.

	Xav

Re: devfs

[john slee]

On Tue, Nov 12, 2002 at 10:43:41AM +0100, Xavier Bestel wrote:
> I'm wondering if a totally userspace solution could replace devs ?
> Something using hotplug + sysfs and creating directories/nodes as they
> appear on the system. This way, the policy (how do I name what) could be
> moved out of the kernel.

curious!  you mean similar to (and a logical extension of) the 'disks'
command in solaris?  at least i think thats what its called...

j.

-- 
toyota power: http://indigoid.net/

Re: devfs

[Sean Neakums]

commence  john slee quotation:

> On Tue, Nov 12, 2002 at 10:43:41AM +0100, Xavier Bestel wrote:
>> I'm wondering if a totally userspace solution could replace devs ?
>> Something using hotplug + sysfs and creating directories/nodes as
>> they appear on the system. This way, the policy (how do I name
>> what) could be moved out of the kernel.
>
> curious!  you mean similar to (and a logical extension of) the
> 'disks' command in solaris?  at least i think thats what its
> called...

Except that a /sbin/hotplug er, "solution", would be dynamic.  I had
always assumed in the back of my mind that such a solution would make
devfs go away some day, although I don't think I actually read about
it anywhere.

Actually, here's a question: are /sbin/hotplug upcalls serialized in
some fashion?  I'd hate to online a thousand devices in my disk array
and have the machine forkbomb itself.

-- 
 /                          |
[|] Sean Neakums            |  Questions are a burden to others;
[|] <sneakums@zork.net>     |      answers a prison for oneself.
 \                          |

Re: devfs

[Oliver Neukum]

> Actually, here's a question: are /sbin/hotplug upcalls serialized in
> some fashion?  I'd hate to online a thousand devices in my disk array
> and have the machine forkbomb itself.

Nope, no serialisation. You don't have any guarantee even that
addition will be delivered before removal.

	Regards
		Oliver

Re: devfs

[Xavier Bestel]

Le mar 12/11/2002 à 10:49, john slee a écrit :
> On Tue, Nov 12, 2002 at 10:43:41AM +0100, Xavier Bestel wrote:
> > I'm wondering if a totally userspace solution could replace devs ?
> > Something using hotplug + sysfs and creating directories/nodes as they
> > appear on the system. This way, the policy (how do I name what) could be
> > moved out of the kernel.
> 
> curious!  you mean similar to (and a logical extension of) the 'disks'
> command in solaris?  at least i think thats what its called...

I don't know solaris (from an admin POV), but I meant something like,
well, devfs. On top of which we could add feature like device naming
stability across system upgrades (I know solaris does that).

Xav

Re: devfs

[Alexander Viro]

On 12 Nov 2002, Xavier Bestel wrote:

> I'm wondering if a totally userspace solution could replace devs ?
> Something using hotplug + sysfs and creating directories/nodes as they
> appear on the system. This way, the policy (how do I name what) could be
> moved out of the kernel.

	Guys, may I remind you that Oct 31 had been more than a week ago?
Devfs *is* a race-ridden pile of crap, but we are in a goddamn feature
freeze, so let's get real.

	Interfaces can and should be cleaned up.  Ditto for semantics of
registering/unregistering - that allows to make glue in drivers more
straightforward.  Majestic flamewars about removing the thing completely/
moving it to userland/etc. are exercises in masturbation by that point.

	Again, WE ARE IN FEATURE FREEZE.

	Now, does somebody have technical comments on the proposed changes?

Re: devfs

[Ian Molton]

On Tue, 12 Nov 2002 05:04:41 -0500 (EST)
Alexander Viro <viro@math.psu.edu> wrote:

> 	Again, WE ARE IN FEATURE FREEZE.
> 
> 	Now, does somebody have technical comments on the proposed
> 	changes?

And since when did feature freeze affect, as the guy said, *purely*
userspace implementations?

(can it be done with current hotplug/sysfs?)

Re: devfs

[Dave Jones]

On Tue, Nov 12, 2002 at 10:25:35AM +0000, Ian Molton wrote:
 > > 	Again, WE ARE IN FEATURE FREEZE.
 > And since when did feature freeze affect, as the guy said, *purely*
 > userspace implementations?

 Since it would a *feature* to move it out of kernel space.
 To reiterate : _FEATURE_ _FREEZE_. Nothing[1] new[2]
 should be going into mainline at this point.

 We should now be in the stabilising period, where we don't require
 testers to have to upgrade their userspace every fortnight.

		Dave

[1] Rusty's modules rewrite and whatever else Linus queed up
    seems to have exemption from this rule. Hopefully there
    isn't too much of this stuff.
[2] Where 'new' can also mean 'bloody large reimplementation'
 
-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: devfs

[Ian Molton]

On Tue, 12 Nov 2002 10:46:50 +0000
Dave Jones <davej@codemonkey.org.uk> wrote:

> > And since when did feature freeze affect, as the guy said, *purely*
>  > userspace implementations?
> 
>  Since it would a *feature* to move it out of kernel space.
>  To reiterate : _FEATURE_ _FREEZE_. Nothing[1] new[2]
>  should be going into mainline at this point.

nothing new WOULD be going in. nor would devfs need to move out - just
disable it. It *is* still an option, is it not?

>  We should now be in the stabilising period, where we don't require
>  testers to have to upgrade their userspace every fortnight.

its not a kernel issue anymore, if its totally in userspace, is it?

Re: devfs

[Rando Christensen]

Tue, 12 Nov 2002 10:46:50 +0000: Dave Jones (Dave Jones
<davej@codemonkey.org.uk>):

> On Tue, Nov 12, 2002 at 10:25:35AM +0000, Ian Molton wrote:
>  > > 	Again, WE ARE IN FEATURE FREEZE.
>  > And since when did feature freeze affect, as the guy said, *purely*
>  > userspace implementations?
>  Since it would a *feature* to move it out of kernel space.
>  To reiterate : _FEATURE_ _FREEZE_. Nothing[1] new[2]
>  should be going into mainline at this point.

Well, it does make sense to start planning out what might be done to
devfs in the /next/ devel kernel, then. If one were so inclined, they
could have a stable enough system for it ready for inclusion next time
around, depending on who they get to test it.

Clean up the devfs API for now, and start working on what might
eventually replace it- Whether that's devfs2 or a purely userspace
implementation or something new and wacky is up to whoever writes it.

Rather than saying "Devfs sucks, and we can't do anything about it other
than fix it's more minor problems because we're in feature freeze", we
should be saying "devfs sucks; we're a little late for feature freeze,
so let's clean up what we can and work on something much better for the
next time around."

Devfs as it is now is a nice idea, to me. It's an extremely organized
/dev which is also an accurate portrayal of what's available to use on a
particular machine. I'd hate to see it just ripped out entirely, and
while they've never affected me, I've heard of many issues with it. I'd
like to hear what ideas people may have /for/ a future replacement.

-- 
< There is a light that shines on the frontier >
<   And maybe someday, We're gonna be there.   >
<    Rando Christensen / rando@babblica.net    >

Re: devfs

[Alexander Viro]

On Tue, 12 Nov 2002, Rando Christensen wrote:

> Rather than saying "Devfs sucks, and we can't do anything about it other
> than fix it's more minor problems because we're in feature freeze", we
> should be saying "devfs sucks; we're a little late for feature freeze,
> so let's clean up what we can and work on something much better for the
> next time around."

Whatever is going to happen with devfs, believe me, the first thing
you'll need is stable glue in drivers - as simple and natural from the
driver POV as possible.  Complexity of doing development in 2.6 will
directly depend on the amount of code in drivers touched by patches.
BTDT - one can carry (and gradually merge) deep rewrites of core code
during -STABLE if it's done carefully.  But as soon as your patchset
hits the drivers - you are in for a world of pain just porting it to
next versions.

_That_ is critical - get interfaces right in -CURRENT, so that further
work would not cross these boundaries; then work in the resulting areas
becomes independent.  

And in situations like that of devfs, simple rules for callers are pretty
much the main criteria - if users of the interface have to jump through
some hoops, it's a sign that interface needs changes...

Re: devfs

[Alan Cox]

On Tue, 2002-11-12 at 10:46, Dave Jones wrote:
> On Tue, Nov 12, 2002 at 10:25:35AM +0000, Ian Molton wrote:
>  > > 	Again, WE ARE IN FEATURE FREEZE.
>  > And since when did feature freeze affect, as the guy said, *purely*
>  > userspace implementations?
> 
>  Since it would a *feature* to move it out of kernel space.
>  To reiterate : _FEATURE_ _FREEZE_. Nothing[1] new[2]
>  should be going into mainline at this point.

Who cares. You can do most of it already with hotplug and the remaining
bits are very much "oops should tell hotplug" bug fixes nothing more.

Alan

Re: devfs

[Ian Molton]

On 12 Nov 2002 14:53:38 +0000
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> >  Since it would a *feature* to move it out of kernel space.
> >  To reiterate : _FEATURE_ _FREEZE_. Nothing[1] new[2]
> >  should be going into mainline at this point.
> 
> Who cares. You can do most of it already with hotplug and the
> remaining bits are very much "oops should tell hotplug" bug fixes
> nothing more.

The more I think about this userspace devfs, the more I like it. simple,
clean, AND doesnt affect the kernel.

Pure coding beauty.

Re: devfs

[Helge Hafting]

Alexander Viro wrote:
> 
> On 12 Nov 2002, Xavier Bestel wrote:
> 
> > I'm wondering if a totally userspace solution could replace devs ?
> > Something using hotplug + sysfs and creating directories/nodes as they
> > appear on the system. This way, the policy (how do I name what) could be
> > moved out of the kernel.
> 
>         Guys, may I remind you that Oct 31 had been more than a week ago?
> Devfs *is* a race-ridden pile of crap, but we are in a goddamn feature
> freeze, so let's get real.
> 
A kernel feature freeze don't apply to a pure userspace implemetation,
so let him try.  :-)  It won't affect the current devfs code, it'll
simply be configured out.
/dev on tmpfs, populated by hotplug. Could be interesting to see.

[...]
>         Now, does somebody have technical comments on the proposed changes?

Only the obvious - a cleanup is generally good and so is getting rid
of unused parameters.

Helge Hafting

Re: devfs

[Greg KH]

On Tue, Nov 12, 2002 at 10:43:41AM +0100, Xavier Bestel wrote:
> 
> I'm wondering if a totally userspace solution could replace devs ?
> Something using hotplug + sysfs and creating directories/nodes as they
> appear on the system. This way, the policy (how do I name what) could be
> moved out of the kernel.

Yes, that is _exactly_ what I am working on doing, and have stated as
such on this list a number of times in the past.

As for it being after the feature freeze comment, like Alan noted,
everything is already present to do this, it's just going to take some
more notifiers being added and some userspace code written.

And no, even if all of this gets done, I would not want to remove devfs
from the kernel, yet :)

thanks,

greg k-h

Re: cerberus errors on 2.4.19 (ide dma related)

[Alexander Viro]

On 18 Aug 2002, Ed Sweetman wrote:

> (overview written in hindsight of writing email)  
> I ran all these tests on ide/host2/bus0/target0/lun0/part1 

Don't be silly - if you want to test anything, devfs is the last thing
you want on the system.

Re: cerberus errors on 2.4.19 (ide dma related)

[Ed Sweetman]

On Sun, 2002-08-18 at 05:10, Alexander Viro wrote:
> 
> 
> On 18 Aug 2002, Ed Sweetman wrote:
> 
> > (overview written in hindsight of writing email)  
> > I ran all these tests on ide/host2/bus0/target0/lun0/part1 
> 
> Don't be silly - if you want to test anything, devfs is the last thing
> you want on the system.
> 
> 


OK, i can remove devfs, but I dont really see how that would make dma
transfers (memory) become corrupted and pio mode transfers (memory) to
not.  

I'm going to remove it, but i dont see how it's going to affect what's
going on. 

Re: cerberus errors on 2.4.19 (ide dma related)

[Ed Sweetman]

It appears i'm completely unable to not use devfs.  Attempting to run
the kernel without mounting devfs results in it still being mounted or
if not compiled in, locks up during boot.  Attempts to run the kernel
and mv /dev does not work, umounting /dev does not work and rm'ing /dev
does not work.  I cant create the non-devfs  nodes while devfs is
mounted and i cant boot the kernel without devfs.  It seems that no
uninstall procedure has been made and i've read the documentation that
comes with the kernel about devfs and it says nothing about how to move
back to the old device nodes from devfs.  

anyone have any suggestions?




On Sun, 2002-08-18 at 05:16, Ed Sweetman wrote:
> On Sun, 2002-08-18 at 05:10, Alexander Viro wrote:
> > 
> > 
> > On 18 Aug 2002, Ed Sweetman wrote:
> > 
> > > (overview written in hindsight of writing email)  
> > > I ran all these tests on ide/host2/bus0/target0/lun0/part1 
> > 
> > Don't be silly - if you want to test anything, devfs is the last thing
> > you want on the system.
> > 
> > 
> 
> 
> OK, i can remove devfs, but I dont really see how that would make dma
> transfers (memory) become corrupted and pio mode transfers (memory) to
> not.  
> 
> I'm going to remove it, but i dont see how it's going to affect what's
> going on. 
> 
> -
> 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/

Re: cerberus errors on 2.4.19 (ide dma related)

[Sean Neakums]

commence  Ed Sweetman quotation:

> It appears i'm completely unable to not use devfs.  Attempting to
> run the kernel without mounting devfs results in it still being
> mounted or if not compiled in, locks up during boot.  Attempts to
> run the kernel and mv /dev does not work, umounting /dev does not
> work and rm'ing /dev does not work.  I cant create the non-devfs
> nodes while devfs is mounted and i cant boot the kernel without
> devfs.  It seems that no uninstall procedure has been made and i've
> read the documentation that comes with the kernel about devfs and it
> says nothing about how to move back to the old device nodes from
> devfs.
>
> anyone have any suggestions?

Where does the boot hang?  If it comaplains about not being able to
open /dev/console or some other device node, it may be that your /dev
has no nodes in it.  This happened to me when I eradicated devfs (I
got fed up of fighting with devfsd to get my permission changes to
stick, and had reshuffled FSes in the meantime) and so I booted from a
rescue disk, mounted my root FS and recreated the device nodes in
/mnt/dev.

-- 
 /                          |
[|] Sean Neakums            |  Questions are a burden to others;
[|] <sneakums@zork.net>     |      answers a prison for oneself.
 \                          |

Re: cerberus errors on 2.4.19 (ide dma related)

[Ed Sweetman]

I know i have no device nodes.  I removed them all before installing
devfs.  the devfs documentation says it doesn't need to have devfs
mounted to work, but this doesn't seem to be true at all.  Hence my
confusion. I know i can go download a bootable iso and get that burned
and working but I shouldn't have to do that.  









On Sun, 2002-08-18 at 14:20, Sean Neakums wrote:
> commence  Ed Sweetman quotation:
> 
> > It appears i'm completely unable to not use devfs.  Attempting to
> > run the kernel without mounting devfs results in it still being
> > mounted or if not compiled in, locks up during boot.  Attempts to
> > run the kernel and mv /dev does not work, umounting /dev does not
> > work and rm'ing /dev does not work.  I cant create the non-devfs
> > nodes while devfs is mounted and i cant boot the kernel without
> > devfs.  It seems that no uninstall procedure has been made and i've
> > read the documentation that comes with the kernel about devfs and it
> > says nothing about how to move back to the old device nodes from
> > devfs.
> >
> > anyone have any suggestions?
> 
> Where does the boot hang?  If it comaplains about not being able to
> open /dev/console or some other device node, it may be that your /dev
> has no nodes in it.  This happened to me when I eradicated devfs (I
> got fed up of fighting with devfsd to get my permission changes to
> stick, and had reshuffled FSes in the meantime) and so I booted from a
> rescue disk, mounted my root FS and recreated the device nodes in
> /mnt/dev.
> 
> -- 
>  /                          |
> [|] Sean Neakums            |  Questions are a burden to others;
> [|] <sneakums@zork.net>     |      answers a prison for oneself.
>  \                          |
> -
> 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/

Re: cerberus errors on 2.4.19 (ide dma related)

[Sean Neakums]

commence  Ed Sweetman quotation:

> On Sun, 2002-08-18 at 14:20, Sean Neakums wrote:
>> commence  Ed Sweetman quotation:
>> 
>> > It appears i'm completely unable to not use devfs.  Attempting to
>> > run the kernel without mounting devfs results in it still being
>> > mounted or if not compiled in, locks up during boot.  Attempts to
>> > run the kernel and mv /dev does not work, umounting /dev does not
>> > work and rm'ing /dev does not work.  I cant create the non-devfs
>> > nodes while devfs is mounted and i cant boot the kernel without
>> > devfs.  It seems that no uninstall procedure has been made and i've
>> > read the documentation that comes with the kernel about devfs and it
>> > says nothing about how to move back to the old device nodes from
>> > devfs.
>> >
>> > anyone have any suggestions?
>> 
>> Where does the boot hang?  If it comaplains about not being able to
>> open /dev/console or some other device node, it may be that your /dev
>> has no nodes in it.  This happened to me when I eradicated devfs (I
>> got fed up of fighting with devfsd to get my permission changes to
>> stick, and had reshuffled FSes in the meantime) and so I booted from a
>> rescue disk, mounted my root FS and recreated the device nodes in
>> /mnt/dev.
>> 
>
> I know i have no device nodes.  I removed them all before installing
> devfs.

You must have been really keen on devfs.

> the devfs documentation says it doesn't need to have devfs mounted
> to work, but this doesn't seem to be true at all.

If it does say exactly that, then it is outrageously wrong.

> Hence my confusion. I know i can go download a bootable iso and get
> that burned and working but I shouldn't have to do that.

Uh, you deleted your devices nodes, and now you want to boot the
system without devfs.  You have to do precisely that, or something
equivalent.

-- 
 /                          |
[|] Sean Neakums            |  Questions are a burden to others;
[|] <sneakums@zork.net>     |      answers a prison for oneself.
 \                          |

Re: cerberus errors on 2.4.19 (ide dma related)

[Barry K. Nathan]

On Sun, Aug 18, 2002 at 07:36:47PM +0100, Sean Neakums wrote:
> commence  Ed Sweetman quotation:
[snip]
> > the devfs documentation says it doesn't need to have devfs mounted
> > to work, but this doesn't seem to be true at all.
> 
> If it does say exactly that, then it is outrageously wrong.

Starting at line 722 of
linux-2.4.19/Documentation/filesystems/devfs/README:

> In general, a kernel built with CONFIG_DEVFS_FS=y but without mounting
> devfs onto /dev is completely safe, and requires no
> configuration changes.

I skimmed through the documentation and it appears to assume that you're
not deleting all the stuff in /dev before switching over to devfs.

> > Hence my confusion. I know i can go download a bootable iso and get
> > that burned and working but I shouldn't have to do that.
> 
> Uh, you deleted your devices nodes, and now you want to boot the
> system without devfs.  You have to do precisely that, or something
> equivalent.

Right, there's no way around that. If you deleted everything in /dev --
which you're not supposed to do -- then there's no way for anything to
find any devices if devfs isn't enabled. (And you should have a rescue
CD around anyway -- you never know when you might need it! BTW, what
distribution are you (Ed) using? Some distributions have special boot
options you can use when booting their install CDs to get into a rescue
mode.)

In any event, it might be a good idea to make the documentation a bit
more explicit about this, and I might send a patch to the mailing
list later today.

-Barry K. Nathan <barryn@pobox.com>

devfs

[Ed Sweetman]

On Sun, 2002-08-18 at 17:53, Barry K. Nathan wrote:
> On Sun, Aug 18, 2002 at 07:36:47PM +0100, Sean Neakums wrote:
> > commence  Ed Sweetman quotation:
> [snip]
> > > the devfs documentation says it doesn't need to have devfs mounted
> > > to work, but this doesn't seem to be true at all.
> > 
> > If it does say exactly that, then it is outrageously wrong.
> 
> Starting at line 722 of
> linux-2.4.19/Documentation/filesystems/devfs/README:
> 
> > In general, a kernel built with CONFIG_DEVFS_FS=y but without mounting
> > devfs onto /dev is completely safe, and requires no
> > configuration changes.
> 
> I skimmed through the documentation and it appears to assume that you're
> not deleting all the stuff in /dev before switching over to devfs.

This has nothing to do with not mounting devfs and still using devfs to
work with devices.   If devfs is not mounted but you're still using
devfs, you shouldn't need anything in /dev.   The documentation says you
can use devfs without mounting and This is what i'm saying is
problematic and doesn't seem possible in normal usage.   It's an
optional config so are we using devfs when we dont mount it or not?  
and if not, then why make not mounting it an option ? 

If it's using the old device files in /dev then how can it be using
devfs and how can accessing physical inodes on the disk be intentional
to devfs? 


> Right, there's no way around that. If you deleted everything in /dev --
> which you're not supposed to do -- then there's no way for anything to
> find any devices if devfs isn't enabled. (And you should have a rescue
> CD around anyway -- you never know when you might need it! BTW, what
> distribution are you (Ed) using? Some distributions have special boot
> options you can use when booting their install CDs to get into a rescue
> mode.)
> 
> In any event, it might be a good idea to make the documentation a bit
> more explicit about this, and I might send a patch to the mailing
> list later today.

I'm not talking about booting without devfs enabled being the problem, i
know booting without devfs enabled I'll have issues booting the system
without physical /dev entries, i was referring to having devfs enabled
and not mounting it.  Which according to the documentation should be
perfectly functional and valid.  This is not the case though.   devfs
should not require the old /dev entries at all since it doesn't use them
so why would keeping them be required at all when using it (not counting
the "if i want to not use devfs" argument).  This is what should be
cleared up in the documentation.  

Re: devfs

[Sean Neakums]

commence  Ed Sweetman quotation:

> On Sun, 2002-08-18 at 17:53, Barry K. Nathan wrote:
>> On Sun, Aug 18, 2002 at 07:36:47PM +0100, Sean Neakums wrote:
>> > commence  Ed Sweetman quotation:
>> [snip]
>> > > the devfs documentation says it doesn't need to have devfs mounted
>> > > to work, but this doesn't seem to be true at all.
>> > 
>> > If it does say exactly that, then it is outrageously wrong.
>> 
>> Starting at line 722 of
>> linux-2.4.19/Documentation/filesystems/devfs/README:
>> 
>> > In general, a kernel built with CONFIG_DEVFS_FS=y but without mounting
>> > devfs onto /dev is completely safe, and requires no
>> > configuration changes.
>> 
>> I skimmed through the documentation and it appears to assume that you're
>> not deleting all the stuff in /dev before switching over to devfs.
>
> This has nothing to do with not mounting devfs and still using devfs to
> work with devices.

If you don't mount devfs, you are not using it to "work with devices".
You use your existing device nodes, unless you deleted them, in which
case you are in trouble, as you discovered.

> If devfs is not mounted but you're still using devfs, you shouldn't
> need anything in /dev.

If devfs is not mounted, you are not "using it".

> The documentation says you can use devfs without mounting [...]

It does not.  It says that if devfs is built as part of your kernel's
configuration and you do not mount it, everything works as before.
For everythign to work as before, your device nodes need to be
present.

> and This is what i'm saying is problematic and doesn't seem possible
> in normal usage.  It's an optional config so are we using devfs when
> we dont mount it or not?  and if not, then why make not mounting it
> an option ?

I can imagine it being useful for for vendors.  Makes it easy to make
devfs usage a simple selection a install time without needsing to ship
two different kernels.

> If it's using the old device files in /dev then how can it be using
> devfs and how can accessing physical inodes on the disk be
> intentional to devfs?

Dunno what you mean here.

>> Right, there's no way around that. If you deleted everything in /dev --
>> which you're not supposed to do -- then there's no way for anything to
>> find any devices if devfs isn't enabled. (And you should have a rescue
>> CD around anyway -- you never know when you might need it! BTW, what
>> distribution are you (Ed) using? Some distributions have special boot
>> options you can use when booting their install CDs to get into a rescue
>> mode.)
>> 
>> In any event, it might be a good idea to make the documentation a bit
>> more explicit about this, and I might send a patch to the mailing
>> list later today.
>
> I'm not talking about booting without devfs enabled being the problem, i
> know booting without devfs enabled I'll have issues booting the system
> without physical /dev entries, i was referring to having devfs enabled
> and not mounting it.  Which according to the documentation should be
> perfectly functional and valid.  This is not the case though.

BECAUSE YOU DELETED YOUR DEVICE NODES.

> devfs should not require the old /dev entries at all since it
> doesn't use them so why would keeping them be required at all when
> using it (not counting the "if i want to not use devfs" argument).
> This is what should be cleared up in the documentation.

devfs does not require your old devices nodes.  Nowhere does the
documentation say that it does.  HOWEVER, if you want to boot a
devfs-capable kernel and not mount devfs (or simply boot a kernel with
no devfs capability at all), you have to have SOMETHING in /dev,
i.e. a set of standard device nodes.

-- 
 /                          |
[|] Sean Neakums            |  Questions are a burden to others;
[|] <sneakums@zork.net>     |      answers a prison for oneself.
 \                          |

Re: devfs

[Alexander Viro]

On 18 Aug 2002, Ed Sweetman wrote:

> This has nothing to do with not mounting devfs and still using devfs to
> work with devices.   If devfs is not mounted but you're still using
> devfs, you shouldn't need anything in /dev.   The documentation says you
> can use devfs without mounting and This is what i'm saying is
> problematic and doesn't seem possible in normal usage.   It's an
> optional config so are we using devfs when we dont mount it or not?  
> and if not, then why make not mounting it an option ? 

What?  If program calls open("/dev/zero",...) and there's no such file,
how the fuck would having devfs enabled help you?

Come on, use common sense - devfs provides a tree with some device nodes.
You can mount it wherever you want (or not mount it anywhere).  Just as
with any other filesystem.

If you mount it on /dev - well, duh, you see that tree on /dev.  If you
do not - you see whatever is in /dev on underlying fs.

If program wants to access a device, it opens that device.  Just as any
other file.  By name.  There is nothing magical about names that begin
with /dev/ - it's just a conventional place for device nodes.

devfs "mount" option is an idiotic kludge that makes _kernel_ mount
it on /dev after the root fs had been mounted.  Why it had been
introduced is a great mistery, since the normal way is to have a
corresponding line in /etc/fstab and have userland mount whatever
it needs.

Said option is, indeed, not required for anything - in a sense that
it does nothing that system wouldn't be perfectly capable of in regular
ways.

But you _do_ need stuff in /dev, no matter what filesystem it comes
from.  Kernel doesn't need it, but userland programs expect to find
it there.  If you had deleted device nodes from underlying /dev and
do not care to mount something on top of it - well, there won't be
anything in that directory.

Re: devfs

[Ed Sweetman]

On Sun, 2002-08-18 at 19:03, Alexander Viro wrote:
> 
> 
> On 18 Aug 2002, Ed Sweetman wrote:
> 
> > This has nothing to do with not mounting devfs and still using devfs to
> > work with devices.   If devfs is not mounted but you're still using
> > devfs, you shouldn't need anything in /dev.   The documentation says you
> > can use devfs without mounting and This is what i'm saying is
> > problematic and doesn't seem possible in normal usage.   It's an
> > optional config so are we using devfs when we dont mount it or not?  
> > and if not, then why make not mounting it an option ? 
> 
> What?  If program calls open("/dev/zero",...) and there's no such file,
> how the fuck would having devfs enabled help you?
> 
> Come on, use common sense - devfs provides a tree with some device nodes.
> You can mount it wherever you want (or not mount it anywhere).  Just as
> with any other filesystem.
> 
> If you mount it on /dev - well, duh, you see that tree on /dev.  If you
> do not - you see whatever is in /dev on underlying fs.
> 
> If program wants to access a device, it opens that device.  Just as any
> other file.  By name.  There is nothing magical about names that begin
> with /dev/ - it's just a conventional place for device nodes.
> 
> devfs "mount" option is an idiotic kludge that makes _kernel_ mount
> it on /dev after the root fs had been mounted.  Why it had been
> introduced is a great mistery, since the normal way is to have a
> corresponding line in /etc/fstab and have userland mount whatever
> it needs.
> 
> Said option is, indeed, not required for anything - in a sense that
> it does nothing that system wouldn't be perfectly capable of in regular
> ways.
> 
> But you _do_ need stuff in /dev, no matter what filesystem it comes
> from.  Kernel doesn't need it, but userland programs expect to find
> it there.  If you had deleted device nodes from underlying /dev and
> do not care to mount something on top of it - well, there won't be
> anything in that directory.
> 

Ok, that all makes sense.  I removed the dev entries because they
weren't needed by me anymore but I suppose it doesn't hurt anything to
just keep them there anyways so I've fixed all that.   Either way,
removing devfs did nothing but apparently it was asked to be done to
allow better testing and/or debugging to be done.  But i've yet to get
any reason why I removed devfs to investigate promise ide controller's
dma related memory failures.  I've removed devfs and replaced the old
/dev entries, no problem.  I'm not getting off topic about that.  It's
all done so i'm waiting for the next step here.  

Re: devfs

[Richard Gooch]

Ed Sweetman writes:
> Ok, that all makes sense.  I removed the dev entries because they
> weren't needed by me anymore but I suppose it doesn't hurt anything
> to just keep them there anyways so I've fixed all that.  Either way,
> removing devfs did nothing but apparently it was asked to be done to
> allow better testing and/or debugging to be done.  But i've yet to
> get any reason why I removed devfs to investigate promise ide
> controller's dma related memory failures.  I've removed devfs and
> replaced the old /dev entries, no problem.  I'm not getting off
> topic about that.  It's all done so i'm waiting for the next step
> here.

It seems the reason you removed devfs is that you followed Al's bad
advice:
Alexander Viro writes:
> Don't be silly - if you want to test anything, devfs is the last
> thing you want on the system.

In fact, devfs works quite robustly for many people, and wasn't
involved in the IDE problems you were having. Al is an absolutist: if
it's not 100% provably correct, it falls into his other category,
"spawn of satan".

So next time someone claims devfs is causing you problems, treat it
with the skepticism it deserves.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: devfs

[Ed Sweetman]

On Wed, 2002-08-21 at 00:49, Richard Gooch wrote:
> It seems the reason you removed devfs is that you followed Al's bad
> advice:
> Alexander Viro writes:
> > Don't be silly - if you want to test anything, devfs is the last
> > thing you want on the system.
> 
> In fact, devfs works quite robustly for many people, and wasn't
> involved in the IDE problems you were having. Al is an absolutist: if
> it's not 100% provably correct, it falls into his other category,
> "spawn of satan".
> 
> So next time someone claims devfs is causing you problems, treat it
> with the skepticism it deserves.
> 
> 				Regards,
> 
> 					Richard....


Ok, well the more happy the people who have the ability to know what the
problem is the better so despite a simple usb issue, moving out of devfs
wasn't a hassle.  I'm willing to move back to vanilla if it helps in
chasing a problem down.  I'm just kind of disappointed that the
discussion of me playing around with devfs got more attention from the
ide guys than the actual problem since it seems to be strictly DMA
related and not a drive problem so if it's chipset conflicts it should
be documented either in the good-bad firmware so the kernel disables dma
on boot of this particular promise chipset when this particular via
chipset is present or in the HELP for the config option so at least
users are aware that drive corruption has been known to happen on the
linux promise driver when dma is enabled on some via chipsets.  That is
unless it's a fixable problem.  Which i rather hope it is.  neither the
abit motherboard or promise controller card are uncommon.   But since
nobody i know has via + promise setups I cant ask them to run the
cerberus test to see the same behavior to see the extent of the promise
+ via problems or if it's even got anything to do with via.  (shrugs)

Re: devfs

[Olivier Galibert]

On Sun, Aug 18, 2002 at 07:03:42PM -0400, Alexander Viro wrote:
> devfs "mount" option is an idiotic kludge that makes _kernel_ mount
> it on /dev after the root fs had been mounted.  Why it had been
> introduced is a great mistery, since the normal way is to have a
> corresponding line in /etc/fstab and have userland mount whatever
> it needs.

I've been wondering, imagine that in the future we have a working
dynamic device filesystem (be it devfs, driverfs, whatever) nice
enough that we don't want a disk-based /dev anymore.  How are we
supposed to mount it so that the kernel's open("/dev/console")
succeeds?

  OG.

Re: devfs

[Greg KH]

On Sun, Aug 18, 2002 at 09:06:18PM -0400, Olivier Galibert wrote:
> 
> I've been wondering, imagine that in the future we have a working
> dynamic device filesystem (be it devfs, driverfs, whatever) nice
> enough that we don't want a disk-based /dev anymore.  How are we
> supposed to mount it so that the kernel's open("/dev/console")
> succeeds?

initramfs might already contain a minimial /dev that has those kinds of
entries in it.

thanks,

greg k-h

Re: devfs

[Barry K. Nathan]

On Sun, Aug 18, 2002 at 06:26:35PM -0400, Ed Sweetman wrote:
> On Sun, 2002-08-18 at 17:53, Barry K. Nathan wrote:
[snip]
> > Starting at line 722 of
> > linux-2.4.19/Documentation/filesystems/devfs/README:
> > 
> > > In general, a kernel built with CONFIG_DEVFS_FS=y but without mounting
> > > devfs onto /dev is completely safe, and requires no
> > > configuration changes.
> > 
> > I skimmed through the documentation and it appears to assume that you're
> > not deleting all the stuff in /dev before switching over to devfs.
> 
> This has nothing to do with not mounting devfs and still using devfs to
> work with devices.   If devfs is not mounted but you're still using
> devfs, you shouldn't need anything in /dev.

IMO the combination of common sense and a little Linux/Unix knowledge
would suggest that you can't use a filesystem if it's not mounted.
(Also, see my next paragraph in this message.)

> The documentation says you
> can use devfs without mounting

No, that's not what it says. It says that you can run a kernel with
devfs enabled but not mounted. This does not imply that devfs is in use
and providing the device nodes, just that it is enabled and present in
the event that it should be mounted.

> and This is what i'm saying is
> problematic and doesn't seem possible in normal usage.   It's an
> optional config so are we using devfs when we dont mount it or not?  
> and if not, then why make not mounting it an option ? 

Why make not mounting it an option? There's more than one reason. You
might want to wait until well into the boot process before mounting it
(I think this one's mentioned in the documentation but I'm not 100%
sure). You might also want to temporarily disable devfs mounting to
avoid a security hole in the event that one is found in devfs, until an
updated kernel is available (this actually happened earlier this year
with recent Mandrake Linux releases that use devfs by default).

> If it's using the old device files in /dev then how can it be using
> devfs and how can accessing physical inodes on the disk be intentional
> to devfs? 

If it's using the old /dev nodes then it's not using devfs -- but you
can switch over later after or during boot.

> > In any event, it might be a good idea to make the documentation a bit
> > more explicit about this, and I might send a patch to the mailing
> > list later today.
> 
> I'm not talking about booting without devfs enabled being the problem, i
> know booting without devfs enabled I'll have issues booting the system
> without physical /dev entries, i was referring to having devfs enabled
> and not mounting it.  Which according to the documentation should be
> perfectly functional and valid.  This is not the case though.   devfs
> should not require the old /dev entries at all since it doesn't use them
> so why would keeping them be required at all when using it (not counting
> the "if i want to not use devfs" argument).  This is what should be
> cleared up in the documentation.  

I believe you misunderstood the existing documentation. Nonetheless it
probably should be clarified, and I'm about to send a patch to the
mailing list.

-Barry K. Nathan <barryn@pobox.com>