> Sure. But I am quite anal about our coding style, so if you have any > worries, you better send it over to someone else - of course I am > kidding (except for the anal part ;-)) I'll change the code style as soon as I'm in the process of cleaning up (I like the way it is coded now, but I am sure there are tons of people who don't agree). I'll send the driver to Philippe to be on the safe side ;-) > > > But which new interface API are you referring to? > > I assumed that the kernel network stack would use a different API, > > because the API between the driver and the current net_server addon > > is private > > and thus undefined. > > It's not private - it's defined and documented in the sample network > driver from Be Inc. > We will continue to use it, at least for a start; we may enhance/change > it a bit over time, though - but we'll always keep backwards > compatibility. I think I don't really agree there. For example, my driver wouldn't work with the realtek addon Be provided. The read hook wouldn't quite work together with what the add-on wanted. So I've written my own very simple addon.