On Sat, Jun 24, 2000, Richard Gooch <rgooch@xxxxxxxxxxxxxxx> wrote:
> 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 shall. I've gotten a couple of requests for HTML versions. I have it
at http://johannes.erdfelt.com/hotswap.txt and I'll most likely create
an HTML version (and abandon a text version) at
http://johannes.erdfelt.com/hotswap.html
[grammar/spelling/english nits deleted]
Thanks. I'll make these fixes.
> > 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).
Will do. I'll add a link to the devfs FAQ as well.
> > 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)?
Perhaps. stat(2) I would think would not require a driver to be loaded, but
I'm not familiar with the specific problems.
> > 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.
Will do.
> > 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?
The general problem is with symlinks pointing to symlinks pointing to
symlinks. Having a whole mess of symlinks would be messy. I want to see
them used, but not abused.
> > 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)?
Perhaps, see above.
> > 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.
How would trees be handled?
/dev/pci/slot0/fn1/usb0/device2/scsi0
Might get a bit ugly.
> > 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?
I'll expand that section.
> > 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?
I hadn't planned to go to OLS, but I have been encouraged to go by a
couple of other developers.
I'll check with my management to see if I can get the company to send me.
I don't suspect it will be a problem if it's a formal BoF or something
similar.
> > 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.
Agreed. I'll spend more time explaining alternative proposed solutions in
addition to the existing implemented solutions I have listed.
> > 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 :-)
I appreciate all of the feedback. The english is minor but is needed.
I have gotten more feedback I have expected from a variety of people. I'll
be working this week to incorporate all of the suggestions and come out
with a new version which I'll invite people on linux-kernel to comment
on.
JE
|