Re: kernel apm code (PR#128)

Re: kernel apm code (PR#128)

[John Fremlin]

sfr@canb.auug.org.au writes:

[...]

> > AFAICS. I hacked together the following patch for it a while ago,
> > which updated APM_IOC_REJECT for slightly more recent kernels (be
> > warned, I think I made some mistakes)
> 
> Thanks for this, I will review it and post a patch based on it (with
> due accredition of course).

Not sure that would be an altogether good idea, because I think I made
a bit of a hash of it ;-)

Did you get Albert Cranford's version?  I would recommend it over mine
(though I have not yet looked at it).

[...]

> I did not say the I did not "like the idea of me implementing it, as
> some people at linuxcare (including Stephen) want to do it
> differently themselves".  

I did interpolate the connection between these two clauses. If it
truely did not exist, I apologise.

> What I said the first time was that I preferred the idea of a user
> mode daemon interacting with the kernel not the kernel forking and
> execing a new process for every event.

This has nothing to do with the interface presented to the APM driver.

[...]

> It is important when implementing an API (and that is what we are
> doing) to try to get it as right and stable as possible because
> other developers do not like interfaces changing ...

Maybe this is true in general but in this particular case the "API"
has only one user at the moment, which is APM, so it is hardly a fully
fledged abstraction layer. Do you argue that the current pm_send_all
interface is superior to the one in my patch?

[...]

-- 

	http://www.penguinpowered.com/~vii