devfs
[Top] [All Lists]

Re: [draft] Hotswap and Linux

To: Richard Gooch <rgooch@xxxxxxxxxxxxxxx>
Subject: Re: [draft] Hotswap and Linux
From: Johannes Erdfelt <jerdfelt@xxxxxxxxxxx>
Date: Mon, 26 Jun 2000 15:15:23 -0700
Cc: devfs@xxxxxxxxxxx
In-reply-to: <200006241921.e5OJLGX12117@vindaloo.ras.ucalgary.ca>; from rgooch@ras.ucalgary.ca on Sat, Jun 24, 2000 at 01:21:16PM -0600
References: <20000621102204.A6504@valinux.com> <200006241921.e5OJLGX12117@vindaloo.ras.ucalgary.ca>
Sender: owner-devfs@xxxxxxxxxxx
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


<Prev in Thread] Current Thread [Next in Thread>