Go to the FreeLists Home Page Home Signup Help Login
 



Browse openbeosstorage: This Month's ArchiveMain Archive PageRelated postsPrevious by Date • Next by Date

[openbeosstorage] Re: Syscall Multiplexing

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: openbeosstorage@xxxxxxxxxxxxx
  • Date: Wed, 01 Oct 2003 02:46:43 +0200 CEST
Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> On 2003-09-30 at 01:24:35 [+0200], Axel Dörfler wrote:
> > Yes, you have add:
> > 1) prototypes for the _kern_ and _user_ calls
> > 2) add the syscalls to kernel/libroot/os/syscalls.S (with the 
> > syscall
> > number and the 32-bit argument count (64 bits are counting twice))
> > 3) do what you said
> > 4) implement the userland part of the syscall (those who call the
> > _kern_*() calls, which could be used from both, the kernel and
> > userland)
> I believe none of the _kern_*() functions will be needed from the 
> kernel. 
> As you might have seen, I pulled most (even all?) of the validate_*() 
> helper functions out of the file and made them available to the rest 
> of DDM 
> implementation (mainly for the implementation of the jobs, which will 
> once 
> again do a check before giving over the control to the modules). 
> There's a 
> certain chance, that those functions will moved into a class with a 
> more 
> pleasant interface, BTW.

From the POV of a syscall, it doesn't make a difference (effort-wise) 
if an API is only available to userland or not. That's the whole point 
behind the story :)

> > I actually never thought of demultiplexing them - I thought of less
> > functions for the user, less syscalls, and most important, less
> > functions to implement for the module programmer :-)
> I'm a bit afraid, that internally the calls need to be demultiplexed 
> anyway, so that it would be multiplexing in userland, demultiplexing 
> in the 
> syscall and multiplexing again for the modules. Not sure though. This 
> needs 
> a bit of investigation.

Why do you think it has to be demultiplexed internally again?
Or do you mean the final implementation in the module? In this case, 
you'd be right, although it would be less write effort to implement 
them :)

> BTW, what is nice about having a non-multiplexed module interface, is 
> that 
> there it is easier to decide, whether a module doesn't implement a 
> hook or 
> whether a request really fails due to some error.

Well, just go on and implement the full intel partitioning system - if 
you then still think that it doesn't have to be multiplexed, then lets 
go for it :-)

Bye,
   Axel.


Other related posts:

  • [openbeosstorage] Syscall Multiplexing
  • [openbeosstorage] Re: Syscall Multiplexing
  • [openbeosstorage] Re: Syscall Multiplexing
  • [openbeosstorage] Re: Syscall Multiplexing
  • [openbeosstorage] Re: Syscall Multiplexing
  • [openbeosstorage] Re: Syscall Multiplexing
  • [openbeosstorage] Re: Syscall Multiplexing




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

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