Hello Christoph,
> That okay in principle, but I'd like to ask you nicely to not touch any
> devfs-related stuff currently. I'ts in flux and any external change
> makes my life in cleaning up the mess a lot harder.
The problem was that the devices disappeared. I did not realize that you
did a typo and they were created at another place, though.
So I rewrote the code for both 2.4 and 2.5 and it worked again.
>>I understand. But delaying the dvb updates just because a few calls to
>>the devfs subsystem (which are now separated by #ifdefs and can easily
>>be found) is not a good option either, or is it?
> I think it is :) Esepcially as you don't just add ifdefs (which give
> me lots of rejects and you much uglier code than just using the
> compat header I'll send to lkml once I'm done with the API changes) but
> you also change the code that's ifdefed for 2.5 to reverse change I
> did. There is a reason why I removed every occurance of devfs_handle_t
> from all drivers and the particular reason is that it will go away in
> the next series of patches.
Ok, I understand.
I promise that I don't touch the devfs related code anymore. But, how do
we proceed in general?
Will the other patches be applied and who does that for which tree?
Shall I resend the patches where you had objections?
CU
Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 07 2003 - 22:00:31 EST