Go to the FreeLists Home Page Home Signup Help Login
 



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







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