From: Darren Hart <dvhart@infradead.org>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Andreas Dilger <aedilger@gmail.com>,
Andreas Dilger <adilger@dilger.ca>,
linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [e2fsprogs] initdir: Writing inode after the initial write?
Date: Tue, 04 Dec 2012 11:40:47 -0800 [thread overview]
Message-ID: <50BE51BF.6020208@infradead.org> (raw)
In-Reply-To: <20121204190829.GA7790@thunk.org>
On 12/04/2012 11:08 AM, Theodore Ts'o wrote:
> On Tue, Dec 04, 2012 at 09:43:21AM -0800, Darren Hart wrote:
>>> "modify_inode" is not a terribly easy use interface. Probably better to add something like "chmod" and "chown" for debugfs as well.
>>
>> I was thinking the same thing.
>>
>
> modify_inode is the old command, and it is indeed hard to use. The
> new one (and the one I use all the time) is set_inode_field
> (abbreviation "sif"):
>
> sif /bin/su mode 0104755
> sif /bin/su uid 0
Ah, excellent.
> BTW, one of the things that I've always toyed with was to create a
> shim layer between the libss API and the tcl embedding API, which
> would add some scripting, aliases, and automation relatively easily to
> debugfs.
>
> What people have done in practice who have cared about this is to
> create perl scripts which emits a series of commands which they then
> feed to a pipe which has debugfs on the other end.
And this is what Andreas suggested with the example bash script. I may
convert
this to a python script, but the concept is sound. That said, I still
feel that
a logical approach would be the following:
1) Update debugfs to completely support our use-case
[ ] Add symlink support
[ ] Add hardlink support
[ ] Add meta-data mirroring
(some of this belongs in the script and not in the ext2fsprogs)
2) Refactor filesystem creation functions from debugfs and move them into
libext2fs alongside existing filesystem creation functions like
ext2fs_mkdir()
3) Add the "-r initialdir" option to mke2fs that leverages these new
functions
from libext2fs.
#3 makes for a more consistent filesystem creation process across
filesystems.
Does this seem like a reasonable approach? Any objection to the migration of
code into libext2fs?
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
next prev parent reply other threads:[~2012-12-04 19:40 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-01 2:13 [e2fsprogs] initdir: Writing inode after the initial write? Darren Hart
2012-12-01 4:23 ` Andreas Dilger
2012-12-01 5:08 ` Darren Hart
2012-12-01 19:31 ` Andreas Dilger
2012-12-03 19:46 ` Darren Hart
2012-12-04 10:45 ` Yongqiang Yang
2012-12-04 17:42 ` Darren Hart
2012-12-04 10:59 ` Andreas Dilger
2012-12-04 17:43 ` Darren Hart
2012-12-04 19:08 ` Theodore Ts'o
2012-12-04 19:40 ` Darren Hart [this message]
2012-12-04 20:00 ` Theodore Ts'o
2012-12-04 20:10 ` Darren Hart
2012-12-04 20:36 ` Theodore Ts'o
2012-12-04 15:22 ` Theodore Ts'o
2012-12-04 17:46 ` Darren Hart
2012-12-04 19:24 ` Theodore Ts'o
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=50BE51BF.6020208@infradead.org \
--to=dvhart@infradead.org \
--cc=adilger@dilger.ca \
--cc=aedilger@gmail.com \
--cc=linux-ext4@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