[lkml]   [1996]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PNP patch into kernel when?

> 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
Linux Plug-and-Play Kernel Project
XFree86 Matrox Team

 \ /
  Last update: 2005-03-22 13:38    [W:0.081 / U:1.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site