More from the Weekday Warriors

More from the Weekday Warriors

[Peter van Hardenberg]

Project News:
-----------------
Alright, today was another good solid eight hour day of Reiser hacking. We 
finally have most of a grip on the specifics of how the pseudo-plugins work, 
how they interface with the filesystem, and so on.

Our plan has further matured: the filedir (pronounced rather like folder) 
plugin will be a regular file-type plugin, and will simply inherit most of 
its methods from file.

As the file-contents will already be monopolizing the i-node, a filedir will 
also have a pointer to a second directory inode which will contain the 
filedir's contents. All directory-related lookups will be routed through to 
that.

The rough implementation plan is as follows:

1) Attempt a trivial change to Reiser and ensure it loads. (Done.)
2) Clone an existing plugin. (In progress.)
3) Replace existing plugin's methods with pass-through methods.
4) Associate a directory (with requisite plugin) with the filedir.

Plugin Project Statistics:
------------------------------
pages of code printed: >200
hours spent reading Reiser4 code: 25
lines of code modified and compiled: 1

Where should attributes live:
------------------------------------
Hans, I like the idea that files should be (for those who want it) treatable 
indistinguishably from directories. The contained-by would get very tedious 
with deep nesting, as that is already how the / translates for me.

I propose this:

files /are/ a normal directory (for resources) and /have/ an invisible 
subdirectory (for attributes) (perhaps "fivedot"?).

The use of a seperate ontological entity for attributes is defensible: first, 
without it, the user attributes are visible in a way system attributes are 
not. More significantly, by separating the two they can be packed differently 
and the attributes could have special properties. Without too much thought 
about the consequences, I'd probably want indexing, two-way compatibility 
with xattr, compression, and perhaps something like size/format restrictions. 
I can think of about a half-dozen other attribute-specific features and 
optimizations I'd want in a perfect world, but I'll leave it at that for now.

Question for the Day:
---------------------------
What files need modification to add a new plugin which does not require inode 
extensions?

How can I set the plugins governing a file from userspace? Can it be done from 
within fourdot? My experiments were unsuccessful.

What would a "hello world" plugin look like? It would be valuable to have one 
lying around for future developers. We have discussed creating one, but I 
feel as though "plugging" and "unplugging" plugins requires a huge amount of 
work right now and that would reduce its utility. Perhaps it would make sense 
if it were distributed as a patch with a plugin developer's guide.

-pvh

-- 
Peter van Hardenberg (pvh@pvh.ca)
Victoria, BC, Canada

Re: More from the Weekday Warriors

[Hubert Chan]

On Wed, 09 Nov 2005 23:47:32 -0800, Peter van Hardenberg <pvh@uvic.ca> said:

[...]

> Hans, I like the idea that files should be (for those who want it)
> treatable indistinguishably from directories. The contained-by would
> get very tedious with deep nesting, as that is already how the /
> translates for me.

> I propose this:

> files /are/ a normal directory (for resources) and /have/ an invisible
> subdirectory (for attributes) (perhaps "fivedot"?).

I don't know how hard it would be, but I think it would be best to make
your code as generic as possible, so that it can be changed to make
subfiles accessible as robert/hat-size, robert/...../hat-size, etc.
(I'm not saying that it should be accessible by those names at the same
time, but it should be possible to, say, make a 10-line change in the
code to switch it from one to the other.)

Intuition is great, and I don't want to downplay it, but IMHO sometimes
it may be more revealing to actually try things out and see how it
works.

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

Re: More from the Weekday Warriors

[Lares Moreau]

[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]

On Wed, 2005-11-09 at 23:47 -0800, Peter van Hardenberg wrote:
> Question for the Day:
> ---------------------------
> What files need modification to add a new plugin which does not require inode 
> extensions?
> 
> How can I set the plugins governing a file from userspace? Can it be done from 
> within fourdot? My experiments were unsuccessful.
> 
> What would a "hello world" plugin look like? It would be valuable to have one 
> lying around for future developers. We have discussed creating one, but I 
> feel as though "plugging" and "unplugging" plugins requires a huge amount of 
> work right now and that would reduce its utility. Perhaps it would make sense 
> if it were distributed as a patch with a plugin developer's guide.

A 'hello world' plugin would be useful indeed to new devs/weekend
warriors,  As for 'plugging' and 'unplugging', we must remember that
reiser4 is coldplug, not hotplug. A hello_world.patch would be great. As
for the PITA factor, I don't feel it is a significant issue, as if you
are hacking the code, you expect things to break and take some time.

I have found in my travels a simple hello_world fs[1] written by Ravi
Kiran[2].  If there could be a page with examples, like [3] for reiser4,
it would be a great benifit to reiser4 as well as the entire fs-dev
community.

As an aside, Geocities.. ICK, we (as a whole) need to get this person a
real web provider IMO.

[1] http://www.geocities.com/ravikiran_uvs/articles/rkfs.html
[2] uvsravikiran@gmail.com
[3] http://www.geocities.com/ravikiran_uvs/
-- 
Lares Moreau <lares.moreau@gmail.com>  | LRU: 400755 http://counter.li.org
Gentoo x86 Arch Tester                 |               ::0 Alberta, Canada
Public Key: 0D46BB6E @ subkeys.pgp.net |           Encrypted Mail Prefered
Key fingerprint = 0CA3 E40D F897 7709 3628  C5D4 7D94 483E 0D46 BB6E

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]