[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <534D9C44.1050505@manux.info>
Date: Tue, 15 Apr 2014 22:53:24 +0200
From: Emmanuel Colbus <ecolbus@...ux.info>
To: Theodore Ts'o <tytso@....edu>, linux-kernel@...r.kernel.org
Subject: Re: [RFC][6/11][MANUX] Kernel compatibility : directory hardlinks
Le 15/04/2014 22:06, Theodore Ts'o a écrit :
> On Tue, Apr 15, 2014 at 03:43:01PM +0200, Emmanuel Colbus wrote:
>> Now for something that has to do both with syscalls and filesystems...
>>
>> My operating system relies heavily upon hardlinks, and, amongst others,
>> directory hardlinks. (Yes, that's what my ext2l partitions are for. Not
>> only, but this is part of it).
>>
>> To allow distinguishing them from true directories, I've introduced a
>> value S_IFDHL equal to 0130000, both for the file mode in stat(2) and
>> for the type_entry field in the dirent structure, in getdents64(2).
>
> Not without more information about what the value means, and what it
> would be used for. See my previous comments about why reserving code
> points for random personal projects is not a something which is at all
> scalable.
>
> - Ted
>
Well, I can give you this information, but first, I would like to
mention that, since Alan Cox has pointed out the fact that the best
thing for me was to simply use a modified ELF header and route my own
syscalls this way, this information has become completely irrelevant. I
mean, since this value would only appear in my little personal ext2l
partitions, and in my own little syscalls, there is no point for you to
do anything anymore, not even reserve it. So, to make it clear, I fully
retract my previous demand.
Now, to give you this information, if you're still interested :
The value means that the file is not a true directory, but a directory
hardlink. Directory hardlinks, which only appear in my ro-compatible
ext2l partitions, are special files that have no content, and simply
point to a directory inode by using its inode number. This value is
simply stored within the fragment address, as my ext2l partitions don't
support fragmentation. As for the kernel, it uses these a little bit
like automatic mountpoint that can't cross partition limits.
But, as I said, that's only a theoretical point now.
Emmanuel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists