In article <linux.kernel.Pine.LNX.4.04.10004182309310.23096-100000@beaker>,
Ricky Beam <jfbeam@bluetopia.net> wrote:
>On 18 Apr 2000, david parsons wrote:
>> Unices I've got available have /dev that looks closer to the old Linux
>> behavior than the new devfs namespace. And FreeBSD (the only of the
>> other free Unices that has survived in my server room) looks, not too
>> surprisingly, very close to the old namespace.
>
>Indeed. This "major/minor" number thing has been around for 30 years. There
>are many _many_ more OSes that still use it.
Yes. Like Linux 2.3.99-pre6-pre3 with devfs enabled. I'm, at least
until someone snaps and provides a kernel-based translation between
the Linus-names and the traditional names, mounting devfs on /devices,
and all the files it provides come with major and minor numbers.
>Now, I'm the last person to stand in the way of innovation, but you've got
>to ask if you're prepared to make linux (incompatablly) unlike anything else
>in existance.
Even in the sort of damaged state it's in right now (mount on /devices,
populate across into /dev :-() it's no more incompatable than on Irix
6.5.
>> I've been playing around with automount (actually amd, which was
>> written by people who would have trouble documenting how to pay a
>> bus driver the US$1.15 to ride the #19 bus into town) and thus
>> can't imagine anything more foolish than entrusting the operation
>> of the system to this particular magic daemon.
>
>That's a little harsh :-)
But true.
>> If it's patched so you can only mount it once, then this ceases to
>> be a problem; the chroot() jails can try to mount devfs until they
>> are blue in their little electronic faces, but devfs will merely
>> laugh (mount: devfs already mounted or /dev busy) at the attempts.
>
>But then everything in the chroot() environment fails because your libc
>malloc uses an mmap() of /dev/null.
Well, for you possible. If I was going to do chroot jails with
devfs as it exists right now, I'd mount devfs on /devices, then
write a devfsd that's only purpose in life was to populate /dev and
/chroot*/dev. Where's /dev/null? /dev/null.
>Dynamic filesystems have their place. However, /dev isn't one of them.
This argument has been done to death, so I'll do my executive summary
for why it is:
/dev is a database of the devices that are attached to the system.
The system should publish, in a usable without black magic form,
this database. It should be published as a filesystem because
that's the natural way for Unix to publish this sort of information
(cf: /proc) and I think that that filesystem should be laid out in
a familiar fashion like the was /dev is already laid out. If the
filesystem can be overmounted (union? inherited? What's the correct
term?) or you don't care about the permissions, it's just a little
something extra that I can put in on /dev and cut out the middleman.
I don't care about the alleged major/minor problem.
>We abandonded the userspace kerneld due to complexity
>and lack of use
Eh? I only abandoned kerneld because it was ripped out from under
me in recent kernels (and now I have to hack modutils so kerneld
doesn't vomit out a long Windows-style "This functionality doesn't
exist in this kernel, so I'm going to quit now [OK?]" message
whenever I load a 2.3.xx kernel. Sigh.) Kerneld provides me with
the useful functionality of being able to use the same kernel on
my install floppies and the installed systems, so if the machine
will boot off an install floppy, it won't unpleasantly surprise
the user and not boot the finished system.
> You don't want the DAC960 driver loaded until
>something accesses it.
You might not, but I do. I build all the block drivers I support
into the kernel and only build modules for pcmcia and usb. I
module-build ethernet, token-ring, slip, and ppp, but the first do
classes are all insmodded when the system comes up (the traditional
Linux approach of hacking something into
/etc/{modules.conf|conf.modules} for ethernet is fairly appalling)
and the latter to are handled by scripts and pppd.
____
david parsons \bi/ Your bog-standard Debian or Red Hat system might
\/ do things a bit differently, but Mastodon isn't
Debian or Red Hat.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:16 EST