Johannes Erdfelt writes:
> This is a little white paper that I've been working on about Linux and
> Hot-Swap and all of the associated problems.
>
> It's a first draft and I'd appreciate any feedback.
This is good work. Could you please make this available as a nice HTML
document and put it up on the WWW somewhere? I'd like to link the
devfs FAQ to it.
I have some minor nits to pick:
> 2. Hot-Swap Interfaces
>
> A hot-swap interface is any interface to a computer which you can plug
> and unplug devices while the machine is running. Insertion and removal
> does not necessarily need to happen while the machine is running, it can
^^^^ ^^
I think "do" and "they" are more correct.
> happen while the machine is off or in a power saving mode.
>
> 2.3 Hot-Swap PCI
>
> Hot-Swap PCI is relatively recent which is mainly seen in servers. It
^^^^^
"and"
> 3.4 Logical Function to Physical Device Association
>
> Given a logical function of a device (say a SCSI drive, /dev/sdb) I cannot
> determine what physical device it is.
>
> For instance, I plug in a USB floppy drive. It appears as SCSI device
^^^^^^^^^^
I'd suggest "corresponds to", so that it drives home the point that
without devfs, device nodes do not "appear" when you plug devices in.
> 4.2 scsidev
>
> scsidev scans /proc/scsi and creates device nodes in /dev dynamically
> depending on the devices on the SCSI busses.
Might be worth highlighting that it's only good for SCSI, and isn't
conducive to adapting to other device types (I've got more detail in
the devfs FAQ).
> 6.1 Required Features for the solution
>
> Some people have had the misconception that this locks everyone into devfs
> to use USB. This is not the case. It locks us into a certain feature set
> that must be supported.
>
> In the case right now, devfs is the only solution which offers all of the
> infrastructure needed.
>
> I cannot see how hot-swap can be implemented in a clean way without these
> requirements.
"without these required features" may be better.
> 6.1.1 Dynamic creation of device nodes
>
> Once configurations and alternate settings are selected, the number of
> interfaces, endpoints can radically change.
^
"and"
> 6.1.2 No fixed limit on device nodes
>
> The structure and layout of device nodes is sparse and complicated
append comma
> quickly outgrowing the entire major/minor space as currently implemented.
>
> This is required to solve the problem described in section 4.2
>
> 6.1.4 VFS intercepts to load modules on demand
>
> Part of the design will track devices and their logical functions. The
> VFS can intercept open() calls for devices and load modules on demand.
Don't you really mean stat(2) calls (in fact, inode lookups)?
> 6.2 Goals
>
> There were goals I strived to meet while I create this solutions
^
singular
> 6.2.1 Minimal code duplication
>
> More and more hot-swap interfaces are coming up and they will all be
> supported. Each solution will have common features which overlap with
> all of the other solutions. For instance, notification of insertion and
> removal to userspace. PCMCIA already has this and USB needs it as well.
>
> This also minimizes the impact into unswappable kernel memory and kernel
^^^^
"on"
> 6.2.2 Intuitive and Clean Architecture
>
> Some other solutions had been suggested to dynamically negotiate minor
> numbers between kernel and user space for device nodes. This is not clean
> nor intuitive and is just a kludge. (Nor does this solution meet all of
> the requirements)
It would help to list those proposed solutions and explain what's
wrong with them. I'll probably steal bits of said material for the
devfs FAQ.
> 6.3 What I did NOT attempt to solve
>
> I did not attempt to solve device naming yet. This is a problem, but
> the best solution that was offered that did not require kernel
> interaction was symlinks. This could become unwieldly with the
> configurations of some systems. Requiring kernel side support may be
> a requirement unfortunately. I welcome any thoughts on this topic.
Can you explain what the problems are with symlinks, and what kind of
kernel solution you suggest?
> 6.4 Description of solution
[...]
> Most of the smarts are in devfsd. I've used the devfsd MFUNCTION to
> intercept REGISTER, UNREGISTER and CHANGE events. This allows us to
> see the insertion and removal of the device, changes to the permissions
> of the device, as well as open() calls on devices with modules that
> are not loaded.
Again, don't you really mean inode lookups, rather than open(2)?
> 6.4.1 USB and Logical Function to Physical Device Association
>
> Using a design from David Hinds (maintainer of the Linux PCMCIA code) I
> propose we create a generic ioctl() interface which can be used to
> retrieve physical device data for a given logical device. This data will
missing "be"
> domain specific and specific to each hot-swap interface.
>
> An alternative solution is to use devfs to create logical device nodes
> as a bus specific node, and create symlinks (/dev/scsi/host0/bus0/target0
> -> /dev/usb/device1/scsi/target0 or something similar).
This is the solution I favour. It makes it easy for the user to
inspect the way things are connected (both physically and logically).
Presenting this information via the filesystem is the most flexible
and convenient method.
BTW: it's more likely to be:
/dev/scsi/host0 -> /dev/pci/slot1/fn1
or some such (for PCI). This is something that is on my ToDo list.
> Both solutions have strengths and weaknesses. An alternative solution may
> also be better. I am confident there is a solution to this problem.
Can you detail the pros and cons?
> 7.1 PCMCIA/Cardbus
>
> A solution similar to this could be implemented to replace the card
> manager and centralize duplicated code and interfaces.
>
> David Hinds has expressed interest in working on a common solution for
> hot-swap interfaces. My solution has involved some ideas from him, but
> he probably isn't comfortable with it yet since we have not talked about
> it or any specific solutions.
Will you and David be going to OLS? What about other people who care
about hot-plug interfaces? If people are going to OLS, we should
arrange to meet up and thrash out the issues. If people can manage it,
come a day or two early or stay on for a day or two (the conference
itself is likely to leave little time).
Otherwise, we should try and arrange some other meeting somewhere do
discuss things. Perhaps SGI would be interested in hosting it?
> 7.2 SCSI
>
> Many, if not all, modern SCSI devices have a unique identifiers which
> could be used to devices. This could be used to track permissions on
^
missing "identify"
> SCSI generic devices (CD burners, scanners, etc) as well as the logical
> function.
>
> 8. Closing Remarks
>
> I expect tweaks to be made when I get input from the kernel developer
> community at large, including those other subsystem that may be
^
plural
> affected including PCMCIA, Hot-Swap PCI, IEEE1394 and SCSI.
[...]
> I also want to reiterate that while I am actively pushing devfs right now,
> that is because it's the best solution available. If an alternative
> solution is developed, and is better, then I am interested in hearing
> about it.
It may be worth stating that many "alternatives" have been proposed,
but they don't address all the problems that devfs solves. A few words
that firmly discourage time-wasting "solutions" and debates which
don't actually solve the problems.
I've seen plenty of posts where people don't actually want to solve
the problems, they just want to throw out devfs.
> Also, please help clear up some of the terminology and descriptions. I
> admit my english and explanations can suck.
Actaully, your document read very well. I'm just a picky bastard :-)
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|