> > David wrote: > > > Philippe, no offense, but I actually want to rip out all sorts of > > > code and reorganise what we have anyways! Given this your code is > > > very useful but I can't help thinking that a totally new clean > > > codebase will be cool and should allow us to have a best possible > > > implementation. > > I would vote +1 for a code reorganisation too. > > Me too, and for a reworked naming scheme (proper prefixes, init/ > shutdown calls: right now, we have destroy, delete, shutdown, > whatever). yes, I'm aware and have tried to tidy up in my recent changes... > > > Well, the R5.x devfs don't let you choose where to put the device > > drivers, as > > he looks for device drivers in these places only: > > A "rescan" finds all drivers, not only those symlinked in .../drivers/ > dev. > But you're right. I am not sure though, if there are any restrictions > on modules. > And we will have only two drivers, the socket driver, and the > networking card driver. > > > We could move all *support* functions into a support module, that all > > modules (core, interfaces, protocols) will use (get_module()). > > > > Kernel modules are like kernel DLLs, except... they're not really :-) > > get_module() / put_module() do reference count, so no multiple > > loads... > > > > pools, mbuf, misc, timers, queues would be better in one network > > support > > module. This isn't as easy as it sounds :( I've had to have a lot of these as functions from core, which isn't a problem, it's just a long list. why? We want all mbufs centrally allocated, and so any function that touches an allocation/free must be done by the core code. > I disagree here - mbuf, and pools are quite usable for others, too. I > would just make different modules for them. We could also consider > reworking the timer to don't have those net_ prefixes and put it in > another module. The kernel defines a timer and so I've used that for the kernel code so far. I'm guessing that's where you got your idea from?:) Hope you're feeling better soon. david