Hi Juergen > I do not complain at all about a slow or not existing process of providing > recent drivers. Sorry - I guess that came across more harsh than it was intended (I probably shouldn't write emails in the middle of the night...)
> Since the list of network cards is unmanageable, there should be very > *small* list of network cards which should be supported and and listed -i.e. > in the forum. Take a look at the Intel Etherexpress cards. As I know you > only need 4 drivers (e100, e1000, e1000e and one compatible) for all intel > based network cards and you're done. At least for basic support. I'm afraid that will only result in endless discussions - to each user, the only drivers that are relevant are the one he/she needs. The list of drivers could probably be cut down, but since the vast majority of those drivers comes with the kernel (and compiling them is rarely a problem), there's no real benefit there, since those setups already exist, and removing them would only create extra work. The ones that tend to cause problems are the ones that don't come with the kernel, that need tweaking to compile. Creating a list of "supported nics" sounds nice for new users, but I'm afraid it might bring all kinds of problems - first of all, who defines what "supported" actually means? Is one test with one card that uses a given chipset enough? If we had tons of users willing to participate in something like that, it would be doable (we have the wiki to put such a list into, and where everybody could add their findings) - but I don't see how a handful of people could pull that off. And then, such a list usually has the tendency to become outdated rather quickly, unless there's somebody maintaining that list who's rather enthusiastic about it, and has access to lots of different hardware. > And what, if your new server has not such a card? You have two choices: > * have an exotic network card, download buildtool, download the driver from > the manufacture, RTFM, configure, compile, run into trouble, restart, do it > again, buy an other nic, do it again - all on your own. Hours over hours ... > days passing ;-) > - or - > * buy for ~ 90 € a NIC with 2 ports - knowing that there is a driver in the > modules tarball ? > > Why not adjusting a little bit the hardware to the software?! That would be an approach - but unfortunately we have little control over what the users do (and many people tend to buy hardware first, and try to figure out if it's supported after that). In short, as Erich pointed out, the issue with newer hardware will continue to get worse as long as we stick with kernel 2.4 - but so far, it doesn't seem bad enough (otherwise, somebody would have chimed in and picked up work on the 2.6 kernel version in the last 12 months). Speaking for myself - Bering uClibc does everything I need, so it's hard to justify spending time on making it do things I don't have a need for. Martin P.S. I don't want to sound all negative about your suggestions - it sounds like every response I give starts with "yes, but..." - I'm just skeptical that they can be pulled off, given the small number of active developers at this point. Just look at http://sourceforge.net/mailarchive/forum.php?forum_name=leaf-cvs-commits and see who committed something to CVS in the last 12 months ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ------------------------------------------------------------------------ leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
