Messages in this thread |  | | From | "Andrew E. Mileski" <> | Subject | Re: PNP patch into kernel when? | Date | Thu, 5 Dec 1996 00:33:58 -0500 (EST) |
| |
> I think I would be happy with that approach. I'd really rather you > resisted the temptation to have the old calls spit out a warning message.
That can be delayed until later, but then there is no motivation to change to the proposed new API.
> Can you envisage a situation in which these old calls would _have_ to > be removed suddenly at some future date? I think developers should be > given some grace period before being harrassed, so there should be at > least one stable kernel release that supports both APIs happily.
I don't know if it is possible, but every attempt will be made to avoid problems. This is in fact why we are discussing this :-)
> I'm not utterly convinced that suddenly changing _all_ references to the > old calls to the new ones in one mammoth patch is necessarily desirable > either, though I don't feel very strongly about it.
The existing hardware resource management API is not strict enough to allow it to co-exist well with Plug-and-Play (PnP). By PnP I mean the detection and configuration of all devices in a system, regardless of the architechture.
Some of the kernel drivers already knowingly abuse the existing API, for the sake of the functionality the proposed new API provides. Still more drivers (nearly all I expect) make assumptions that are not allowed with PnP, and the existing API allows/expects/promotes this.
In order for PnP to be integrated into the Linux kernel, there has to be _some_ fundamental changes. There is no escaping this. The benefits should out-weigh any inconvenience caused though.
-- Andrew E. Mileski mailto:aem@ott.hookup.net Linux Plug-and-Play Kernel Project http://www.redhat.com/linux-info/pnp/ XFree86 Matrox Team http://www.bf.rmit.edu.au/~ajv/xf86-matrox.html
|  |