[openbeosnetteam] Re: skeleton sockets fd support driver
- From: philippe.houdoin@xxxxxxx
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Thu, 28 Feb 2002 13:49:34 +0100 (MET)
> 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.
Yep, I'm starting to feel bad about that:
my select() test I add this morning can't be considered valid until someone
test it against a non-BONE BeOS kernel.
I'll reinstall a orignal BeOR R5.0.3 ASAP...
> Bear in mind we're actually writing the stack in userland at the moment!
I know that :-)
But under BeOS (and NewOS, AFAIK), there is only one way to offer a file
descriptor: open() call.
So to connect an open() call to a socket, we could:
- write a file system driver
- write a driver and let the already written devfs file system offer file
descriptor for free.
The later's simpler, hence my choice.
> 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.
Under R5, sockets are NOT file descriptors, but some *handle* to a endpoint
managed by the net_server. You can't close() them, nor read/write() them.
File descriptors support offered by BeOS kernel, apart the select() support
which I'm in the process to evaluate, works fine, thanks to kernel.
This skeleton driver try to fill the missing fd sockets support, something that
R5 net_server don't offer and make harder to port many Unix network apps to
BeOS, PostgreSQL for one I know about.
With this driver and the socket upper api in my lib/socket.c, sockets would be
real file descriptors.
>> 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.
Could you explain why?
Something I miss about how one library offering all network-related api (mostly
BSD sockets and BNet* classes) is bad?
What's make splitting it better?
UNIX ports, maybe?
> OK. But as we're not yet at the point of writing our own drivers...
No, not yet. ;-)
But it's something we need to addressed, as it's the major reason behind the
lack of network file systems under BeOS...
>> The libnet.so use this mechanism to create a valid, file descriptorized
>> socket. And to do the real job behind connect(), etc...
>> libnet.so will use the driver too to offer a configuration api...
>> using some special socket file descriptor...
>
> Hmmm, can you expand on that?
Real file descriptors can only be returned from the kernel open() call.
So, the library open() the path published by the driver "/dev/net/stack" (which
give her back a file descriptor). Then, implemeting sockets calls like
connect() call is simply a matter of ioctl(BIND_OPCODE, bind_params) on the fd
returned previously. And so on.
For configuration/control, the library could simply open the driver and
communicate with the stack via special ioctl() opcodes on the driver, up to him
to relay these ioctls to net_server.
Anyway, this point is secondary now, but maybe I would look at an ifconfig
source code to learn more how this kind of tool communicate with the net
stack...
> Huh, R5 doesn't have syslog.
Sure it does. It's the syslog_daemon server purpose...
From userland, see file:///boot/develop/headers/be/support/syslog.h
From kernelland, I dunno, but dprintf() could be redirect to it, it's not
enabled by default, that all.
Look at your /boot/home/config/settings/kernel/drivers/sample/kernel: there is
a syslog_debug option there... Move the sample file into parent folder, and set
this option to true. Starting next reboot, look at /var/log/syslog. You should
see lot of drivers message there.
> Axel has some ideas but we really need to get the linbet.so / libsocket.so
> working ASAP.
Yes. So, next big step is the lib <-> net_server IPC.
The better the IPC design could works between kernelland <-> userland too, the
easer it would be to add fd sockets support, but you right, it's not that
urgent.
So, who have boring day job and want to design this IPC?
;-)
-Philippe.
Other related posts:
