[Top] [All Lists]

Re: [draft] Hotswap and Linux

To: Johannes Erdfelt <jerdfelt@xxxxxxxxxxx>
Subject: Re: [draft] Hotswap and Linux
From: Richard Gooch <rgooch@xxxxxxxxxxxxxxx>
Date: Mon, 26 Jun 2000 23:38:30 -0600
Cc: devfs@xxxxxxxxxxx
In-reply-to: <20000626151523.P5810@xxxxxxxxxxx>
References: <20000621102204.A6504@xxxxxxxxxxx> <200006241921.e5OJLGX12117@xxxxxxxxxxxxxxxxxxxxxxxx> <20000626151523.P5810@xxxxxxxxxxx>
Sender: owner-devfs@xxxxxxxxxxx
Johannes Erdfelt writes:
> 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 and I'll most likely create
> an HTML version (and abandon a text version) at


> > > 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.

If the inode doesn't exist, then any attempt to reference it by name
(stat(2), open(2), chown(2) and so on) will cause an inode lookup. If
the device entry hasn't been registered, this will cause a LOOKUP
event to be sent to devfsd.

If the inode does exist (or the device entry has been registered),
then there is no need to load a module upon open(2), as the module is
already loaded (otherwise the device entry wouldn't exist).

> > > 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.

Agreed. I see two levels of indirection, which I think is reasonable,
given what we're trying to represent:
/dev/discs/disc0 -> /dev/scsi/host0/bus0/target0/lun0
/dev/scsi/host0  -> /dev/bus/pci/slot1/fn1

> > > 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.

/dev/discs/disc0 -> /dev/scsi/host0/bus0/target0/lun0
/dev/scsi/host0  -> /dev/usb/device2/scsi0

If you want to expose which USB controller is being used, then:
/dev/scsi/host0  -> /dev/usb/controller0/device2/scsi0
/dev/usb/controller0 -> /dev/pci/slot1/fn1

> > 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.

Larry hasn't spent all those buckets of money yet, has he? I'm sure VA
can afford it :-)

> I don't suspect it will be a problem if it's a formal BoF or
> something similar.

Given that I expect the conference to have a tight schedule, and that
we probably need more than an hour to thrash out the ideas, I'd rather
do it just before or after the conference. I figure I can get the
Linuxcare people to provide us with some space for an afternoon.

> 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.

Will you be passing the next draft to the devfs list for comment
before unleashing it on linux-kernel?


Permanent: rgooch@xxxxxxxxxxxxx
Current:   rgooch@xxxxxxxxxxxxxxx

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