public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Emmanuel Colbus <ecolbus@manux.info>
To: "Theodore Ts'o" <tytso@mit.edu>, linux-kernel@vger.kernel.org
Subject: Re: [RFC][6/11][MANUX] Kernel compatibility : directory hardlinks
Date: Tue, 15 Apr 2014 22:53:24 +0200	[thread overview]
Message-ID: <534D9C44.1050505@manux.info> (raw)
In-Reply-To: <20140415200629.GI4456@thunk.org>

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



  reply	other threads:[~2014-04-15 20:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-15 13:43 [RFC][6/11][MANUX] Kernel compatibility : directory hardlinks Emmanuel Colbus
2014-04-15 20:06 ` Theodore Ts'o
2014-04-15 20:53   ` Emmanuel Colbus [this message]
2014-04-15 22:01     ` Theodore Ts'o
2014-04-15 23:12       ` Emmanuel Colbus
2014-04-15 23:34         ` Theodore Ts'o
2014-04-16  2:14           ` Emmanuel Colbus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=534D9C44.1050505@manux.info \
    --to=ecolbus@manux.info \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox