From: Stefani Seibold <stefani@seibold.net>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Alexey Dobriyan <adobriyan@gmail.com>
Subject: Re: [PATCH] Fix proc_file_write missing ppos update
Date: Sat, 12 Sep 2009 17:57:48 +0200 [thread overview]
Message-ID: <1252771068.29135.25.camel@wall-e> (raw)
In-Reply-To: <20090912152814.GG5858@ZenIV.linux.org.uk>
Am Samstag, den 12.09.2009, 16:28 +0100 schrieb Al Viro:
> On Sun, Aug 30, 2009 at 09:05:44PM +0200, Stefani Seibold wrote:
> > Switching all users of read_proc_t/write_proc_t to file operation is a
> > huge job. About 180 files must be fixed.
> >
> > But the main reason not to do this is because the breakage of "out of
> > tree" drivers.
>
> > I like the current simplified proc interface. It saves a lot of code
> > duplication because the basic operations will be handled inside the
> > kernel and not in the driver.
>
> _What_ code duplication? Would that be
> struct proc_dir_entry *pde = PDE(file->f_path.dentry->d_inode);
> and calculation of pde->data currently done by proc_file_write()?
> Pardon me, but that's hard to take seriously. As for the ->read() side,
> most of those suckers end up switched to use of seq_read() and there's
> not a lot of boilerplate code in the resulting variants...
Hi Al, you are 2 weeks to late, the discussion has already ended. But
lets start it again....
There is some code duplication, proc_file_write has 17 lines of code.
And together with my path it will be 19 lines of code. How much lines of
duplicated code are necessary for take them seriously?
I know that the current mainstream development targets enterprise and
maybe sometime desktop systems. But the truth is that linux will be
mostly used in embedded system with very limited memory constrains.
BTW: I personally think the whole seq_.... interface is IMHO to
complicate to use, procfs is much simpler. But this is only my personal
opinion!
Greetings,
Stefani
next prev parent reply other threads:[~2009-09-12 15:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-29 16:38 [PATCH] Fix proc_file_write missing ppos update Stefani Seibold
2009-08-29 23:16 ` Christoph Hellwig
2009-08-30 8:09 ` Alexey Dobriyan
2009-08-30 19:10 ` Stefani Seibold
2009-08-30 19:05 ` Stefani Seibold
2009-08-31 6:33 ` Alexey Dobriyan
2009-08-31 15:44 ` Arnd Bergmann
2009-08-31 17:19 ` Alexey Dobriyan
2009-08-31 17:21 ` Christoph Hellwig
2009-08-31 20:19 ` Arnd Bergmann
2009-09-12 15:28 ` Al Viro
2009-09-12 15:57 ` Stefani Seibold [this message]
2009-09-12 20:51 ` Eric W. Biederman
-- strict thread matches above, loose matches on Subject: below --
2009-08-07 20:27 Stefani Seibold
2009-08-07 20:58 ` Andrew Morton
2009-08-07 21:43 ` Stefani Seibold
2009-08-07 22:16 ` Andrew Morton
2009-08-08 6:59 ` Eric W. Biederman
2009-08-08 9:29 ` Stefani Seibold
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=1252771068.29135.25.camel@wall-e \
--to=stefani@seibold.net \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
/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