[openbeos] Attribute support on foreign OS (was Re: Storage Kit)

  • From: François Revol <revol@xxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Sun, 04 Nov 2001 03:29:48 +0100 (MET)

En réponse à Travis Geiselbrecht <geist@xxxxxxxxxx>:

> is a Bad Idea (TM). In the replacement api there is no concept of
Hehe I'm not the only one to have those =)

> attributes, but if/when I get around to implementing it, it will be
> similar to the Be way, which involves having a readattr/writeattr/etc
> call. I am still keeping the concept of stream types though, and will
> probably implement openattrdir/readattrdir/etc by opening a file with
> a
> STREAM_TYPE_ATTRDIR type or something like that.

Talking about filesystems...
One idea I had for a long time already, I would be surprised if others didn't 
think about it already, but let me tell anyway (hopping it's a Good Idea (TM))
This maybe of more interest to the BlueOS team, but I think others might
concerned.

We already talked here about attribute support under Linux for instance
(when talking about possibly using Linux as a OBOS kernel),
and we said that we would either have to make a bfs driver for Linux,
or add attribute support to XFS or another one.
The problem is Linux doesn't support attributes _at the VFS layer_.
So we could add attribute support on say XFS, how would we tell the XFS to 
read an attribute from foo.txt since we must speak to the VFS which doesn't
know what an attribute is ?
2 solutions I see for that:
- patch the Linux VFS to add attribute support: well, dunno if Linus will like 
it. -> Depends on Linux maintainers.
- use something I myself never really have used in coding, the IOCTL call.
the IOCTL is there to "perform a variety of control functions on devices and 
STREAMS".
Attributes are exactly the kind of services that aren't stream based.
So why not make use of this ?
This way we can get through the VFS layer to talk to the modified XFS driver
or even an full bfs driver with attributes support.
But I think we should define the interface so we get "official" IOCTL codes
so that we don't interfere with something else, and each attribute aware  
filesystem will use the same IDs.
This would help porting BeOS apps to Linux (hehe), help the BlueOS team,
and maybe Travis would want to use this way to either intercept the IOCTLS 
back to attribute calls or use it as a possible implementation (not sure it's 
the best layout though, but this would save 3 or 4 calls in the 
already-crowded fs_calls structure :D )

See you,
François.


Other related posts: