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.
> > But first I have to fix the devfs API on 2.5 and randomly bringing
> > back old crap and lots of ifdefs in those changing areas won't help.
>
> 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.
-
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/