Linux-kernel mailing list archive 1998-31,: Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)

# Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)

Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Thu, 6 Aug 1998 01:08:11 +1000

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Andries.Brouwer@cwi.nl: "[PATCH] keyboard.c"
- Previous message: Andrea Arcangeli: "Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)"
- Next in thread: Andrea Arcangeli: "Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)"
- Reply: Andrea Arcangeli: "Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)"
- Reply: Andrea Arcangeli: "Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)"

Andrea Arcangeli writes:
> On Thu, 6 Aug 1998, Richard Gooch wrote:
>
> >before I wrote devfs. But then when you buy a shiny new disc, you have
> >to go and create inodes again.
>
> Since you have also to dismount your hardware, recompile the kernel and
> reboot, running `MAKEDEV audio` after the boot is not so difficult.

No, this isn't true. Think about hot-swappable discs. Think about
PCMCIA. Think about USB. All cases where hardware is plugged in and
out and you don't reboot the kernel.

> >> 2. I don' t know very well the fs code but I don' t think the problem
> >> is the number of inodes, but instead the number of file entry in the
> >> directory /dev/. So dividing /dev/ in /dev/block /dev/char for example
> >> would speed up things I think.
> >
> >Yes, it helps a bit. But the problem just gets shifted to a
> ^^^
> Something like O(n*log(n)) instead of O(n).

Erm, if you just move all block devices into their own subdirectory,
and assuming the bulk of /dev bloat is due to block devices
(reasonable, when you consider the zillions of possible SCSI discs
when we break the 16 disc limit), then searching through /dev/block is
nearly as long as searching /dev with everything in it.

> >> I don' t know if devfs is so malleable/configurable.
> >
> >I'm not sure what you mean here. Do you mean having subdirectories?
>
> root@dragon:/tmp# cp -a /dev/hda3 .
> root@dragon:/tmp# mount /tmp/hda3 /park
> mroot@dragon:/tmp# mount
> /dev/hda1 on / type ext2 (rw)
> proc on /proc type proc (rw)
> /dev/hdc on /cdrom type iso9660 (ro,noexec,nosuid,nodev,unhide)
> /tmp/hda3 on /park type ext2 (rw)
> ^^^^^^^^^
> root@dragon:/tmp# umount /park

Not a problem. Just leave CONFIG_DEVFS_ONLY as 'N' (the default).

> Can you send me your latest devfs to give a try? I tried to download from
> the www site but it seems to stall from here.

Yup. I'll send it privately, though :-)

Regards,

Richard....

-
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.altern.org/andrebalsa/doc/lkml-faq.html

- Next message: Andries.Brouwer@cwi.nl: "[PATCH] keyboard.c"
- Previous message: Andrea Arcangeli: "Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)"
- Next in thread: Andrea Arcangeli: "Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)"
- Reply: Andrea Arcangeli: "Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)"
- Reply: Andrea Arcangeli: "Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)"