[openbeos] Re: struct stat st_mode bits
- From: "François Revol" <revol@xxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 01 Dec 2004 23:29:32 +0100 CET
> "François Revol" <revol@xxxxxxx> wrote:
> > > BFS could use this internally, and although the original one
> > > doesn't,
> > > my implementation actually does. It's not really needed though,
> > > so
> > > we
> > > could think about removing it.
> > Doesn't tell me what it does...
>
> Ah, okay. I should have said if the directory/container in question
> supports duplicate entries or not. For indices this is generally
> true,
> for other types, it's not :)
>
> > > > Also I'd reconsider using S_FOO_INDEX in favor of S_INDEX,
> > > > since
> > > > it's not very scalable... we have only 2 bits left in that
> > > > field.
> > > I don't understand what you're trying to say here.
> > Are the different bits really needed or could we use just one to
> > say
> > S_INDEX without type distinction ?
>
> They are actually used by BFS to maintain the index type. Although it
> also duplicates this information in the B+tree header, we now also
> use
> it to report the types when calling stat() on an index.
>
Or what about using the bits as value instead of bitmask ? would give
more room,
S_IFMT does it (see LNK, and SOCK... wait, where are my sockets gone ?
I need sockets for santa to put things in !!!!!)
/me goes add S_IFSOCK back
(Yes we do can use that type for sockets even in R5. It's just about
not using a device driver which publishes only char devices. sockfs
works great here with BONE, I'll port it to our stack)
François.
Other related posts:
