Go to the FreeLists Home Page Home Signup Help Login
 



[openbeosnetteam] || [Date Prev] [09-2002 Date Index] [Date Next] || [Thread Prev] [09-2002 Thread Index] [Thread Next]

[openbeosnetteam] Re: stack

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: openbeosnetteam@xxxxxxxxxxxxx
  • Date: Mon, 16 Sep 2002 23:43:28 CEST (+0200)
Philippe wrote:
> > I meant the object modules, not the source code! It would be really 
> > silly to have different source code locations.
> > What I meant was: it should be easily possible (most of the time) 
> > to 
> > load the kernel modules from the userland stack and just use them 
> > without the need to recompile them for userland usage.
> Without recompilation???

That's what I thought, yes :-)

> Kernel addons are linked against _KERNEL_.
> It's written in their image ELF table.
> How come we can tell the BeOS loader that he should consider our 
> userland net_server as "_KERNEL_" image instead of the kernel real 
> image!?!
> 
> Please, if the fs-kit userland journey make figure you some speels on 
> this area, 
> could you share with us mortals?

The fs-kit userland stuff is completely compiled for userland, there is 
no loaded kernel module (although I've thought about doing this).
Since BeOS has this strange loader (IMHO), there might be two solutions 
to this: 
1.) set the soname of the executable to _KERNEL_
2.) have a link _KERNEL_ that points to your app

I dunno about 2.), but 1.) should really work, I haven't tried it 
though.
Of course, it will only work if there are only functions called that 
exist in userland. Since BeOS has this nice kernel design where you 
just use libc functions, and what else exist in the C interface in 
userland, it should be kind of easy to get it working.
If everything fails we could still use the OpenBeOS loader for the 
network stack and let it load the kernel module without bothering about 
the _KERNEL_ reference at all ;-)

Adios...
   Axel.







[ 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.