> You also need a 'class' so you can initialise things like block, then char,
> then net
Of course. It seems I've chosen a too large compression ratio when writing
my ideas :-))
> > Unfortunately, this probably requires calling the PNP BIOS to get all the
> > regions magically occupied by motherboard hardware :-(
>
> It needs to call arch dependant code. PnP bios isnt very common on an alpha.
Yes. Each architecture should register its own onboard devices when
initializing the resource manager.
> > driver and everything is done. [We can also use kmod to notify
> > userland about new device appearing which needs to be named.]
>
> And to do stuff like load firmware
Good idea.
> > (4) The bus-dependent code receives an unplug notification and sends
> > it to the driver. The driver releases the device, bus-dependent
> > code removes it and deallocates all of its resources. Done.
>
> What if the driver says "Im in the middle of something" or "but there
> is an fs mounted".
In such cases, the driver needs to propagate the unplug information
to all devices connected to it before it uninitializes itself.
> Just to remind you its -not- trivial 8)
:-)))
> ISAPnP is simpler than hot plug PCI and you have to do it in kernel space
> to handle power management right, to handle clash avoidance and to handle
> PCI/ISA IRQ route programming on the southbridge
Yes, but the decisions on what resources should be assigned to what
devices should be definitely left to userspace programs as they are very
complex and it's wise to make them overridable by some config file.
> CardBus is basically hot plug PCI
Yes, but I'm not sure about the details.
By the way, I remember that some time ago you were talking about I2O
needing some special resource allocation -- can you tell me more about
these issues, please?
> What about platforms with multiple spaces where an 'address' (ie a void *)
> is insufficient to describe an object ?
:-(( Until now I didn't know about any such architecture. I'm afraid that
any solution to this problem will be ugly. For accessing the devices in the
kernel we can make ioremap() a bus-dependent function, but it does solve
neither resource management issues nor user-level access via /dev/mem.
I hope I'll hear the opinion of people maintaining the architectures where
this appears soon.
> There is no need for an isa_readb() - readb() will be right. ioremap will be
> required for ISA anyway.
Ok.
> As to the endianisms, please _dont_ do that. It encourages bad programming.
> Instead of thinking how to avoid endian swaps people will write sloppy code
> that just endian swaps every reference
I don't like that, too, but currently on some architectures readl() at al.
swaps bytes _always_, but many devices are able to switch their MMIO
to big endian, so that the driver can avoid swaps at all. I'm only not sure
whether the complexity of making use of this is adequate to the speed gain.
Have a nice fortnight
-- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "Don't take life too seriously -- you'll never get out of it alive."- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/