Re: Device API: Implementation
Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]>
| Newsgroups | gmane.os.openbeos.storage |
|---|---|
| Message-ID | <[email protected]> |
On Thu, 13 Feb 2003, Axel =?iso-8859-1?q?D=F6rfler ?= wrote: > "Ingo Weinhold" <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> 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