
|
[openbeosstorage]
||
[Date Prev]
[12-2002 Date Index]
[Date Next]
||
[Thread Prev]
[12-2002 Thread Index]
[Thread Next]
[openbeosstorage] Re: First C Device API Draft
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Sat, 28 Dec 2002 20:34:21 +0100 CET
"Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> I was almost starting to implement it, when I started wondering
> whether
> it would be better to return/pass a pointer to the module itself, not
> just the name. This would even save the overhead for loading/
> unloading
> the module each time. Then the caller would be responsible for
> calling
> put=5Fmodule() (unless a NULL module=5Finfo** had been supplied or the
> returned pointer was NULL). How does that sound=3F
Sounds okay, I think... at least it must be documented that you have to
do that :)
> I'm not longer sure, whether it is possible at all.
> B=5FGET=5FPARTITION=5FINFO has to be called on the partition device, not on
> the raw device, and I wouldn't know how to get hold of it (it's in
> the
> same dir as the raw device, but that doesn't really help...).
Where is the problem=3F AFAICT the devfs directs all calls to the raw
device, altering the position and size of the read/write calls,
answering to ioctl()s the raw device cannot know about, etc.
> OK. But then we should find a way to fill it in for the time being,
> since one would certainly like to use it in implementation of the C++
>
> API.
The "df" command also lists the mount point of the volumes, should be
possible, although it obviously uses a private call =5Fkstatfs=5F() :-)
Adios...
Axel.
|

|