[openbeosstorage] Re: API Extensions
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Sat, 28 Dec 2002 21:13:17 +0100 CET
"Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> I reconsidered the partitioning matter and came to the conclusion,
> that
> the functionality should indeed be provided by the partition modules.
> The argument, that GUI code for asking the user for the required
> parameters wouldn't feel very happy in kernel modules, is of course
> still valid, and therefore it should go into userland add-ons. As a
> consequence the parameters must be passed to the kernel modules, and
> to
> do that, there has to be a way to identify a module from userland.
Sounds reasonable.
> typedef bool (*partition=5Fidentify=5Fmodule=5Fhook)(const char *
> identifier,
> uint32 version);
> typedef status=5Ft (*partition=5Fpartition=5Fhook)(int deviceFD, const
> struct
> session=5Finfo *session, void *parameters, size=5Ft paramLen);
The information should be queryable through an ioctl - so you can ask
the device which partition system it is using.
> For FS initialization the FS modules would need similar functions:
>
> typedef bool (*fs=5Fidentify=5Fmodule=5Fhook)(const char *identifier,
> uint32
> version);
> typedef status=5Ft (*fs=5Finitialize=5Fhook)(int deviceFD, const struct
> partition=5Finfo *partitionInfo, const char *volumeName, void *
> parameters, size=5Ft paramLen);
I don't think the fs initialization should be part of that module, I
think it should be part of the file system driver. Initializing a file
system might not be as easy as it is in FAT :-)
Especially for BFS, it would require to copy big parts of the code.
But of course, there should be a simple way to check if a particular
file system supports initialization - the current DS doesn't do that,
so it presents all file systems to the user at that point, which we
should be able to avoid.
> typedef status=5Ft (*disk=5Fscanner=5Fpartition=5Fhook)(int deviceFD, const
> struct session=5Finfo *session, const char *identifier, uint32 version,
> void *parameters, size=5Ft paramLen);
> typedef status=5Ft (*disk=5Fscanner=5Finitialize=5Fhook)(int deviceFD, const
> struct partition=5Finfo *partitionInfo, const char *identifier, uint32
> version, char *volumeName, void *parameters, size=5Ft paramLen);
What exactly is the "identifier" doing in the partition hook=3F
> And the user functions:
> status=5Ft partition=5Fsession(int deviceFD, int32 sessionIndex, const
> char
> *identifier, uint32 version, void *parameters, size=5Ft paramLen);
> status=5Ft initialize=5Fpartition(int deviceFD, int32 sessionIndex, int32
> partitionIndex, const char *identifier, uint32 version, char *
> volumeName, void *parameters, size=5Ft paramLen);
I would replace the second with:
status=5Ft initialize=5Fvolume(const char *where, const char *fileSystem,
const char *volumeName, const char *parameters);
Or something similar, probably in unistd.h (accompanying mount()).
> class BDiskScannerParameterEditor {
> public:
> virtual ~BDiskScannerParameterEditor();
>
> virtual BView *View() =3D 0;
> virtual status=5Ft GetParameters(void **parameters, size=5Ft *paramLen)
> =3D 0;
> };
>
> How does that sound=3F
Looks very nice! There also should be a default parameter editor for
file systems, where you can just enter the name of the volume (in the
case there is no dedicated add-on for it).
I also have some other notes:
1) All partitioning systems I know (Intel & Amiga RDB) have special
identifiers for the file system which is installed on a particular
partition - for example 0xeb/0xbe for BFS in either little or big
endian in intel partitions.
The current approach seem to ignore those completely, which we have to
do in a way, because they aren't compatible between different
partitioning systems. But is this valid=3F It would make it possible to
initialize a partition marked as BFS with the FAT driver - that's not
nice, but I don't think we can do anything about it.
OTOH we can use this information to display names for partitions with
unknown or initialized file systems - so that Tracker displays "Be
volume" or "QNX volume" if the recognizes a BFS/QNX partition but it
cannot read the file system for whatever reason.
That functionality is already part of the current BeOS in some way
(i.e. it shows "IDE Master 1:Partition 0" or something like this for
unknown partitions).
2) Is there support for hidden partitions=3F
We might also have special driver settings for the partition modules,
although I am not yet sure where we can use it (to hide intel
partitions for example).
3) Almost all file systems need to have a look in the first 1024 bytes
of a partition - it's not very efficient to let every file system have
to allocate a buffer and read that data in. This access is not cached -
if we have 10 different file systems (which might happen very fast),
and the last one happen to be the one who says "this is my volume", we
would most probably have to allocate and read this data 10 times
physically from the disk.
It would be much nicer if the sniffer function would pass a buffer and
a position/size like this:
sniff(..., void **buffer, size=5Ft *=5FbufferSize, off=5Ft *=5Foffset, ...);
Or have it pass a pointer to a function which the sniffer can use to
get data from the partition - it could directly return a buffer.
That way, we wouldn't need to read that data over and over again, and
we also wouldn't need to allocate/deallocate the buffer over and over
again.
Adios...
Axel.
Other related posts:
