On Wed, 12 Apr 2000, Michael H. Warfield wrote:
> Are you sure about that? For some reason, I was under the impression
>that a special file (block or char device) didn't occupy any FS blocks. I
Sorry for the confusion... I'm refering to drive space in general. There
are two types of space in a file system... inodes and data. Special files
don't take any data space (with the possible exception of symlinks); they
only waste an inode with is one FS block -- the '-b' part of mke2fs. They
better not be using any data space -- they don't contain any data.
>du is lying through it's teeth.
Well, du has been known to lie :-) It depends on what it's adding up as
"size" (number of data blocks or the size reported by stat.)
Inodes aren't counted as space... 'df -i' reports that kind of stuff. I've
never been a big fan of "the UNIX way" (tm) of handling file systems. (I
really like the simplicity in the OS-9 [RTOS] file system.)
> Come on now. Solaris royally sucked if you went to the /devices
>directory but it only mildly sucked if you went to the /dev directory
devfs makes /dev look alot more like the solaris /devices than anything
else. How long do you think it will be before pci id's end up in the devfs
name tree? (And don't say it won't because I know damn well it will.)
> /devfs is fine with me, but I though the $#@$# thing booted on
>/dev. In fact, a check of 2.3.99-pre5 confirms it. It's not overlaying
>/devfs, it's going over /dev unless you tell lilo append="devfs=nomount"
>and then mount devfs on /devfs yourself in /etc/fstab (which is exactly
>what I'm doing right now).
Alright, that's it. This is grounds for immediate execution. The only thing
the kernel should ever mount without an explicit sys_mount() is the rootfs
(and someone told it what to mount there.) The kernel should never, and I
repeat, in caps, NEVER, mount something I didn't tell it to mount.
(And if you _must_, why the bloody fuck don't you automount /var/shm!)
>> If you wanted to be a purist, modules need a new function for reporting
>> devfs information... init_module, delete_module(?), devfs_module? That
>> certainly fixes one problem (and kills the need for devfsd.)
>
> Bizzzt... Wrong answer. Actually, it's a great idea and I wish it
>would solve the problem. Unfortunately, it doesn't solve the problem for
>USB, PCMCIA, Firewire, hot-swappable SCSI, hot-swappable IDE, or any other
>thing (the list goes on and on) where devices may come and go while the
HOT SWAP is an evil unto itself. In the case of "who the hell knows"
hardware, devfs only needs to know of the directory inwhich the node
belongs to autoload the module. However, in most cases, loading at
first access is too late. Look at USB... if you plug in a device that
does have a driver but isn't loaded, the usb core will complain about
no registered driver for it. In such cases, it'd be up to the core
to ask for a module to be loaded.
Devfs isn't very useful here unless you have a robotic arm to plug/unplug
USB devices for you *grin*
> Now if there were only a CLEAN solution to the non-volatile
>attributes problem. Set permissions and ownership of a device. Device
If you define "clean solution" as '/usr/bin/vi'... either alter the
settings in the source or reset them everytime it's loaded.
--Ricky
-
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 : Sat Apr 15 2000 - 21:00:19 EST