
|
[openbeosnetteam]
||
[Date Prev]
[04-2002 Date Index]
[Date Next]
||
[Thread Prev]
[04-2002 Thread Index]
[Thread Next]
[openbeosnetteam] Re: Now it seems this thing works! :)
- From: "David Reid" <dreid@xxxxxxxxxxxx>
- To: <openbeosnetteam@xxxxxxxxxxxxx>
- Date: Wed, 3 Apr 2002 16:31:29 +0100
> > Not exactly. We can just create a libselect.so and link any programs
> > that want to use our select() call to it. Adn we can do it now (no need
> > to wait for NewOS.
>
> But what about binary compatibility!?!
> apps using select() link againts:
> - libnet.so, libroot.so, etc
> or
> - libsocket.so, libroot.so, etc if BONE-required apps.
>
> If we want to support both kind of these apps, wihtout recompile them,
> our new select() should be in libnet.so or libroot.so. It can't be
> in a new library.
>
> Beside that, one library for such a small single call, woa ;-)
> Making a libselect.so symlink targetting libnet.so will be
> much smaller ;-)
>
> > And we don't need to. Note that our net stack will replace the
> > net_server one so this select() won't even exist anymore.
>
> Correct.
>
> > As I said, it does not have to be libroot.
>
> Without recompilation, it *should* be for BONE-apps, 'cause it's where
> they *expect* the select() call.
> It just a matter of binary or not binary compatibility there.
>
> > BONE would also be replaced by our implementation. I guess we just
> > need a way to make it possible to link a program against
> > libroot.so and our libselect.so without conflicts.
> > Is it possible at all? Can we check
> > inside the library if libroot (or any other library for that matter)
> > exports the symbol and do not export ours? This way we would use the
> > BONE kernel select() when present.
>
> We can check in libnet.so select() call, at runtime, if the libroot.so
> export a select() function symbol, yes, and call this one instead of
> using our *hack* (which is only for R5.0.3- kernels).
> I will try to implement this.
>
> > Dunno. How can I know? Well... According to David, our version is
> > broken. :)
>
> According to David, the R5.0.3- kernel select() don't honnor the timeout
> argument. Never.
> The test I've done last month don't let the timeout end, because the test
> make a call to notify_select_event() explicitly after 2 seconds,
> so I can't explains why.
> The R5.0.4+ kernel works fine, as your own test show: it returns 1, not 0
> (timeout) or -1 (error).
> Currently, the /dev/net/socket don't pass the libnet.so select() timeval
> argument but use always a one second timeout...
>
> > But it will be possible now, thanks to OpenBFS. We must make things
> > easier for everyone else.
> > That would help. But what do we do with binary distributions? Some
> > users won't like having to compile stuff. Maybe provide a BONE and
> > non-
> > BONE version?
>
> That rights, having two version of libnet.so is a painfull.
> Let's find a better way...
>
> > While we are at that, wouldn`t you happen to know how to fix our
> > select()?
>
> Yes, but as said I don't test if the timeout condition works fine.
> I'll try to find why.
> Anyway, if R5.0.3- kernel select() don't honnor the timeout
> argument, we can add start an alarm before calling it and, this way,
> wakeup the select() call when our alarm signal raise.
OK, if you can get it working it'll be very cool!
>
> Okay, tonigh I'll focus on trying to fix the select() support.
> But I still don't know where the read, write and exception events
> should be triggered. sowakeup(), David?
Sort of...
If you get the timeout thing fixed I'll post with more info on how we need
to watch for events...though there is a comment in socket.c with more
information!
david
>
> -Philippe
>
>
|

|