Go to the FreeLists Home Page Home Signup Help Login
 



[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: philippe.houdoin@xxxxxxx
  • To: openbeosnetteam@xxxxxxxxxxxxx
  • Date: Wed, 03 Apr 2002 17:26:26 +0200 (MEST)
> 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.

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? 

-Philippe





[ Home | Signup | Help | Login | Archives | Lists ]

All trademarks and copyrights within the FreeLists archives are owned by their respective owners.
Everything else ©2007 Avenir Technologies, LLC.