> A word of caution about using a BONE system for testing/development. > The > code we have so far won't run on a BONE system, and the target > platform is a > non-BONE system. Why should it not work? They aren't that different. You just have to not use that driver from within BONE. > > - BSD sockets api: socket(), bind(), connect(), listen(), accept(), > > etc. Bonus, sockets are file descriptors too (welcome to inetd, > > select() pooling, etc). > Now, quick question. Are you sure? R5 has a LOT of issues about fd's/ > sockets > so this will need careful checking and I'm not sure it'll remove all > the > restrictions. Well, at least we should check - the notify_select() function is also defined in the R5 kernel, but we can't be sure it will work until we've tried. > Doh! ioctl and so on should be used for these. We will *not* be > linking > directly against the stack for ifconfig or any other tool. Yep. > > BTW, for previous [Open]BeOS network api compatibility, BONE's > > libsocket.so and libbind.so, like libbnetapi.so could be easily > > symlinked > to > > use this all-in-one libnet.so... > Why??? Man, that's a big backwards step. Not really - it's more or less the same with libbe.so: there is all the stuff you need in it. But there is always more you could need from one little application. But since it has to be in memory anyway, why not put them together in the same library? (well, I would be fine with having different libraries, but at least the stack communication would have to be done only once) > > In his current skeleton stage, this driver do nothing but > > allocating any > > "fake" endpoint asked by libnet.so and logging into syslog. > Huh, R5 doesn't have syslog. Of course it has. You have to enable syslog output for kernel drivers, but it has all the functionality you need. > Nice to see people actually doing more! Yep, you're not the only one anymore :) Adios... Axel.