[lkml]   [2003]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] /proc/ide/hdx/settings with ide-default pseudo-driver is a 2.6/2.7 show-stopper
    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". :-\


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:48    [W:0.024 / U:44.048 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site