Messages in this thread | | | From | Bartlomiej Zolnierkiewicz <> | Subject | Re: [RFC] /proc/ide/hdx/settings with ide-default pseudo-driver is a 2.6/2.7 show-stopper | Date | Thu, 28 Aug 2003 20:39:39 +0200 |
| |
On Thursday 28 of August 2003 20:06, Alan Cox wrote: > On Iau, 2003-08-28 at 16:47, Bartlomiej Zolnierkiewicz wrote: > > > Its also used to avoid special cases elsewhere. > > > > /proc/ide/hdX/settings is the source (directly/indirectly) > > for 95% of these special cases. > > /proc/ide/foo/identify is another (and tools rely on that working > without ide-cd/ide-disk etc loaded btw) [HP monitoring tools for one]
Eeeh... easy to workaround: no settings -> drive->id doesnt change. There is minor problem here: no driver -> driver -> no driver.
> > Why for hotplug? We should move all code physically touching > > devices to use request queue (REQ_SPECIAL), then you can simply > > mark device as unplugged when its gone and check this flag inside > > ide_do_request(). > > Because you need to manipulate drives not attached to a driver > currently. I guess you could go through hoops to avoid it, but the > old IDE driver was just full of bugs that ide_default removed, > and it removed rather more code than it added.
Heh.. bugs yes, code not :).
> You also need to be able to open the device to talk to the empty
You can't open devices owned by ide-default in 2.6 because ide-default, probably because it doesnt call add_disk() for them.
> slot about reprobing it, changing the bus state or even figuring > what driver is missing.
I think scsi does it without default driver. procfs or sysfs
> > With this scheme you also shouldn't need hwif->unplugged_ops hack. > > You mark all drives belonging to hwif as unplugged and you are happy. > > You need the unplugged_ops for controller unplug, I'm more worried about > disk unplug (which I have working now). For controller unplug you either
So you can unplug disk in the middle of the transfer, replug and transfer is continued?
> have to know that ide_unregister does not ever return until the device > is truely idle - including interrupts, proc access currently running > etc. If so then notionally you can handle it without the unplugged ops > although they certainly make it safer. > > I don't know what the constraints on PCI hotplug are but I don't believe > anything will run off and reuse the resources after an unplug event, > although your accesses might generate machine checks (non fatal) on IA64 > etc. > > > Problem is when integrating ide with driverfs. > > Then you need to register/unregister ide-default as driverfs driver > > and now it can "steal" devices, ie. you have cd drive owned by > > ide-default, later you load ide-cdrom driver and your cd drive needs to > > be unregistered from ide-default driver first before it can be registered > > with ide-cdrom driver - you need to add code to do this or device will be > > "stealed". Its not very hard to do but it adds complexity. > > My own feeling is that its a lot easier than trying to catch all the > corner cases ide_default fixed, especially when you do drive level > hotplug. If the IDE code was glorious and elegant, refcounted and with > a clear life cycle of objects I'd agree with you 8)
Eeehh... okay I will try "plan b". :-\
--bartlomiej
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |