Go to the FreeLists Home Page Home Signup Help Login
 



[openbeosstorage] || [Date Prev] [02-2003 Date Index] [Date Next] || [Thread Prev] [02-2003 Thread Index] [Thread Next]

[openbeosstorage] Re: Device API: Implementation

  • From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
  • To: openbeosstorage@xxxxxxxxxxxxx
  • Date: Thu, 13 Feb 2003 21:38:11 +0100 (MET)
On Thu, 13 Feb 2003, Axel =?iso-8859-1?q?D=F6rfler ?= wrote:

> "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > When you receive a notification message, you only get IDs and need to
> > retrieve the respective objects, if you want more than that. The
> > required data are available in the registrar only. Well, with a path
> > to
> > a device, the API in libbe could of course directly use the
> > disk=5Fscanner functions to get the information, but that will be
> > rather
> > slow considering that the registrar has an always up to date device
> > list.
>
> Well, syscalls should be faster than message passing, so that up-to-
> date list is probably not that beneficial (at least I think so).

If you don't keep an up-to-date list somewhere, you'll have to run the
disk_scanner functions everytime you want that information. And these are
magnitudes slower than a quick message exchange with the registrar.

If the kernel keeps an up-to-date list anyway, the syscalls to fetch the
data are, of course, faster than the communication with the registrar.

To state my point of view cleary: I'm not entirely sure, that dealing with
the disk device stuff in the registrar is the best solution. Maybe the
kernel would be the better place. The kernel has some advantages, like
better performance, and later it may be necessary to copy/move much, if
not all, of the functionality there to be able to implement the nice R2+
features.

But there are also problems. To maintain an up-to-date list of disk
devices, I want to use node and mount event monitoring, and that is
currently not available. If we will provide it, things look different.
Furthermore there is the general question to be asked: Is it necessary to
implement that functionality in the kernel? Since I currently don't think
it is, I would tend to leave it in userland, unless there are unbeatable
benefits.

> > > Sounds nice! As for the FS initialization: the file system call
> > > should
> > > be more or less the same as the mount() call.
> > > I will add some calls to the FS API for discussion shortly, this
> > > will
> > > also affect file system initialization.
> > Very nice. I'm waiting with bated breath. ;-)
>
> Don't do that too long :-))
> I think I will first complete the stdio almost rewrite before following
> the next topic :)

Fair enough.

CU, Ingo






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