Re: reiser4 plugins

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hans Reiser wrote:

Lincoln Dale wrote:

the irony of this whole thread is that history is repeating itself. see http://www.ussg.iu.edu/hypermail/linux/kernel/0112.1/0519.html
kernel developers pushed back on you 3 years ago - in 2001 - what has
really changed?

It is exactly the same, but rather than dwell on that, I'll just remind
that I have sent out two technical emails which talk only about the
issue of plugins and pluginids, and whether plugins are classes rather
than just instances, and whether the classes really would benefit from
being instantiated into VFS at the cost of keeping the same info in two
places, and I got no answer on them.  Zam pointed out that our plugins
do more than just VFS operations, and got no response on that or his
other points.

Regarding trust, Christophe comes out the gate using the words "useless
abstraction layer" that happens to be a core feature of our design,
demanding we cut it out, and not really understanding it or recognizing
any functionality it provides, and you can't really expect me to respect
this, can you?
heh. one example i didn't mention in the myriad of EVMS, IPv6, IPSec et al was iSCSI. Christoph was (rightly so) very strong in pushing back on things that needed to be fixed/changed/addressed in linux-iscsi, a project near & dear to much of the paid work i do.

while i'm sure Christoph could probably be more tactful at times, his views on technical matters in the kernel are respected. the key here is to not take it personally - but instead just understand that this is the framework that you have to work in to get it into the mainline kernel.

if you don't want to go down that path, you're free to do so. its open source, you can keep your own linux-kernel fork. but if you want to get your code into mainline, i don't think its so much a case of l-k folks telling you how to make your code work under VFS. the onus is on you to say WHY your code and plugins could never be put into VFS.

if anything, you should be thankful that Al hasn't yet commented. :)


Now, if his target is reduced to whether we can eliminate a function
indirection, and whether we can review the code together and see if it
is easy to extend plugins and pluginids to other filesystems by finding
places to make it more generic and accepting of per filesystem plugins,
especially if it is not tied to going into 2.6.13, well, that is the
conversation I would have liked to have had.

fantastic - some common ground.
any reason WHY there has to be an abstraction of 'pluginid' when in theory VFS operations can already provide the necessary abstraction on a per-object basis?

Nikita basically said as much in Message-ID: <[email protected]> earlier in this thread: "But it is not so. There _are_ plugins-in-the-VFS. VFS operates on opaque
    objects (inodes, dentries, file system types) through interfaces:
    {inode,address_space,dentry,sb,etc.}_operations. Every file system
    back-end if free to implement whatever number of these interfaces. And
    the do this already: check the sources; even ext2 does this: e.g.,
    ext2_fast_symlink_inode_operations and ext2_symlink_inode_operations.

    This is exactly what upper level reiser4 plugins are for.

    I guess that one of Christoph Hellwig's complaints is that reiser4
    introduces another layer of abstraction to implement something that
    already exists."

i never saw any reason why there can't be specific VFS operations put together for specific inodes if the policy for that inode dictates any special operation (e.g. compression).



cheers,

lincoln.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux