Re: API Extensions

> 
> "Ingo Weinhold" <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote:
>
> > 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.

I guess, one would make devfs intercept this ioctl and ask the 
disk_scanner and friends?

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

Yep, see my other mail.

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

Agreed. There are also other properties of a FS that are of interest 
(not for initialization, but for a complete device API), e.g. if it is 
read-only, supports attributes/queries/...

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

A copy'n'paste leftover. :-)
Just wanted to know, how carefully you're reading. ;-)

> > 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()).

Mmh, I could live with that, though it doesn't fit with the rest of the 
functions.

Perhaps it's also better to drop that `version' stuff. I thought, it 
could help to deal better with situations when different versions of a 
FS exist, but probably that's a bit too esoteric.

> > 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 actually thought to have these editors edit only the FS specific 
parameters while the volume name would always be editable with the 
presented GUI. In case there were no add-on/editor only the volume name 
could be entered.

> 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

I've done this more than once, accidentially mostly. :-)

> - that's not 
> nice, but I don't think we can do anything about it.

Me neither.

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

The extended_partition_info features both the type code 
(`partition_code') and a human readable interpretation 
(`partition_type'). partition_code is uint8 currently -- maybe it 
should be resized to uint32.

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

The Device class has a function DisplayName() that returns something 
like that (`IDE master bus:1') for devices it knows (IDE and SCSI), for 
others the device name (after `/dev/disk') is returned (`virtual/0').

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

The extended_partition_info structure has a fields `flags' which can 
have the bit B_HIDDEN_PARTITION set (it was a `bool hidden' in the DS 
add-on partition_data structure, IIRC). The partition add-ons are 
supposed to set that bit, if the partition is a non-data partition 
(e.g. an extended one). But I suspect, I are driving at something else, 
aren't you?

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

That's right. I decided to stick close to the DS add-on in this 
respect, since I realized, that it would at least not be sufficient to 
read only the first logical block and that FSs store their super block 
at different location (ReiserFS after 64 KB).

> This access is not cached -

In fact I didn't know that. :-P

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

That sounds good! I definitely favor this solution.

CU, Ingo