Sorry for the late reply. Been busy.
Theodore Y. Ts'o writes:
> Date: Sat, 13 Feb 1999 08:24:32 +1100
> From: Richard Gooch <[EMAIL PROTECTED]>
>
> 1) it would be slow
>
> Why do you think it would be slower? Most machines have relatively few
> devices in /dev, and the dcache takes care of the remaining performance
> issues. The trick would be the daemon would make sure that only the
> required devices would be populated in /dev.
It's slower because there are context switch and communication
overheads between the kernel and the daemon. You don't need that with
the devfs approach. I'm not saying that your approach is "too slow",
just that it is slower. I prefer to avoid slower approaches, even if I
don't have a definate measure of what is "fast enough".
It's also slower when opening up devices because of the inode->device
operations translation needs to be done with a non-devfs scheme. Right
now that translation is done by indexing into the major number
tables. When we break past 8 bit majors, we're looking at a search
scheme (like the current misc driver) or a hash+search scheme.
Again, devfs doesn't require this.
> 2) it would require a patch that is essentially the devfs patch minus
> the ability to mount a FS (the device information still needs to
> be recorded in a database, devfs includes the ability to access
> that database via a FS).
>
> No, because the only information you need is which major numbers,
> and for disks, which minor numbers are available (possibly filling
> in a bitmap). The database which maps the the major/minor numbers
> to actual names would be a file which is read by the daemon. I'd
> probably have the default permissions in the system file, but have
> an overridable file which the local system administrator could edit
> if he/she wanted to override either the default name or permissions.
> If you're really clever, you could automatically generate the
> database file from the devices.txt file --- or that might become the
> new format for the devices.txt file.
OK, I see what you mean now. But then how do you support autoloading
of modules? If you don't have a special FS (like devfs), then you
can't pass the name being looked up to kmod.
This scheme doesn't work too well either if you want to have NTFS as
your root FS, for example. I've thought about initrd, but I don't
think that actually can help you, because initrd doesn't do anything
with /dev, it only mucks around with / which doesn't really help us
here.
> The point is that you can do all of this in user space, and not keep
> all of the filename information in the kernel, where (a) bloats the
> kernel, and (b) makes it hard for the local system administrator to
> override the names or permissions, if necessary.
I don't think this is true: there *are* things you can do with devfs
but I don't think you can do with any alternative scheme.
> If designed properly, the patch should require far fewer mods to the
> kernel than the devfs patch.
Possibly, but you'd lose some of the features of devfs.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
