Re: DevFS vs. udev

[Bradley W. Allen]

Thank you for the cogent reply.  I think all your substantiated
points are valid.  I'll have to see what I can do about the rest,
as you said.

I'm glad others responded to what seems like an inaccurate post of
mine.  At least I, if not others, can persue it as was suggested
by you and Greg KH <greg@xxxxxxxxx> for now.

I am not volunteering at this time to work on DevFS.

The main problem is documentation, as you pointed out.  I went to
"make menuconfig" in the new stable kernel, and ran into this problem
head-on:  help for that option says that it is either depracated
or obsolete, and after using it without big problems for a long
time, I wanted to know why.  Everything I saw after that smelled
bad, and I'm saying so, but that may not mean that it is.  It was
so bad I didn't even read the "paper" about why on one of the
referenced web sites.  Also, my old 3 year archive via USENET
of linux-kernel no longer exists within my grasp (not any fault of
mine), so I'm forced to use web archive access, and it's hard to
navigate in those.

To respond to Greg KH, my uses are not for a highly production
oriented mission critical corporate system or anything, but they
are timing critical.  If it takes more CPU, RAM, and time to open
/dev/null and all the other hundreds of devices in /dev that get
opened every time some programs start, that is not only bloat, but
more trouble.  Moving kernel functions into user space has always
been a pet peeve of mine:  why do it, when it just means shuffling
back and forth between system calls and user processes ... if that's
what is actually happening ... unless that's not what's happening
...  I'll have to research this myself at some other time.

okay.  So I don't know what I'm talking about within /dev internals
in the kernel.  It's just not well documented.  I can read the
documents, then know what I'm talking about there, but all I'm
trying to do is install 2.6.  Ok, so I could have taken the word
of the help system.  Meanwhile, I've had to spend at least half
a day re-configuring a non-DevFS /dev for the first time in half
a decade in preparation for this big depracation, and I am upset
about it.

Sure, I could continue to use DevFS, but if as you said, it's not
going to be around long, then I could be in trouble for depending
on it.

I'm going to use disk /dev for now, until I have time to understand
this better, which will probably be around halfway through next year.

Already, I'm living the old pain I thought was left way behind of
archiving and moving around /dev subdirectories, and having to
consider the differences between systems, kernels, distributions,
and versions of backup, something I thought I didn't have to worry
about.  If udev gets OK or DevFS doesn't break, I may go back to
that someday.

For now, if whatever I do doesn't slow the system down more
than about .1 seconds per access of *all* the /dev/ devices
necessary for a complete program transition (in a swapping
Pentium III), then I should be OK.  Perhaps that was
unconsciously nagging me:  userspace =? swap; swap every time
/dev gets accessed?  If indeed this is just an undocumented
transition, then my confidence is higher that you've made
sure this isn't a problem, and I just didn't read about it.
In one of my uses, /dev doesn't get accessed very often,
perhaps once every half hour (giving it plenty of chance to swap
if it has that ability, which I don't want it to), but when it
does, it expects sub-second turnaround on the entire lot.
If udev doesn't actually get used during device opens and closes,
then that will fix that problem.  Too many unanswered questions.

Sorry for the "emotional" fuss.  (Perhaps my personal environment
needs less of that pressure, too :? )
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/