On 2007-04-05 at 04:20:47 [+0200], Mat Hounsell <mat_geek@xxxxxxxxxxxx> wrote: > I see from CIA RSS feed that the FS API dox has been written [1]. Nice. It's far from being complete, though. As of yet I've only written the part of the API required for a simple read-only FS and an, admittedly uninspired, introductive text, basically a collection of thoughts on some topics. Other important topics, like the cache interfaces, are not covered yet. > But the question I have glancing over it is what functions do I use to > implement the FS? Like how do I wuery the partition size and refere to > locations inside it? The kernel provides a subset of the POSIX API available in userland, most interestingly open(), close(), fstat(), ioctl(), read_pos(), write_pos(). For performance reasons one usually doesn't directly read from/write to the underlying device, but uses either or both of the file system caches (block cache and file cache, yet undocumented). Regarding the size of the device, you usually fstat() it first. If it is a regular file (disk image), st_size is all you need. In case of a block device you'll have to use the B_GET_GEOMETRY ioctl() (cf. <drivers/Drivers.h>) to get a device_geometry structure for it, and compute the size by multiplying the relevant fields. > The DOS FS is a bit complex for an example fs [2]. An FS that treats a > partition as having a single file would be a clearer example. IIRC, Be had sample code for a "one file file system". I don't see it in /boot/optional/sample-code, so I suppose it was only on Be's website. It's probably still available in the depths of The Net. It would use BeOS's file system interface, of course, but that's not so vastly different from Haiku's, so most things will still apply. > The third question; is fs_shell [3] etc up to date? Documented? The FS Shell uses the BeOS FS interface. Other than that it is up to date and undocumented, AFAIK. CU, Ingo