public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jakob Oestergaard <jakob@unthought.net>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Joe Thornber <joe@fib011235813.fsnet.co.uk>,
	Andi Kleen <ak@muc.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Device-mapper submission 6/7
Date: Fri, 18 Oct 2002 13:38:06 +0200	[thread overview]
Message-ID: <20021018113806.GD7875@unthought.net> (raw)
In-Reply-To: <3DAEEB59.2000000@pobox.com>

On Thu, Oct 17, 2002 at 12:54:49PM -0400, Jeff Garzik wrote:
...
> Preferred method of data input is always ASCII, but if that is 
> unreasonable, make sure your binary data is fixed-endian and fixed-size 
> on all architectures.

But Jeff, won't the kernel end up with a myriad of
sort-of-similar-but-all-different parsers, with each their set of
overflows, *(int*)0, etc. etc. ??

This sounds like /proc - just the other way around. Today the kernel
generates everything from one-value-per-file to friggin ASCII art in
it's proc files, and userspace is cluttered beyond belief with myriads
of parsers, sort of similar but all different.

And now you want parsers in the kernel?  Not just a few, but like
*myriads*...

I really like the idea with having
  mv  volume1 volume42
as a way of renaming a volume.

Compare that to
  echo "rename-volume volume1 volume42" > volume_command_file

I doubt that there will be much that cannot be mapped to standard
filesystem semantics. Plan9 has TCP *connections* as files...

At least I think that this should be considered thoroughly. I fear that
we will end up with something worse than procfs in a year from now, if
the current trend is "just make a command file and a parser in the
kernel" now.

Just my 0.02 Euro.

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

  reply	other threads:[~2002-10-18 11:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-15 17:58 [PATCH] Device-mapper submission 6/7 Joe Thornber
2002-10-15 18:15 ` Jeff Garzik
2002-10-15 18:59   ` Greg KH
2002-10-15 21:44   ` Joe Thornber
2002-10-16 14:20     ` Jeff Garzik
2002-10-16 14:38       ` Anton Blanchard
2002-10-16 15:20         ` Jeff Garzik
2002-10-16 15:20       ` Joe Thornber
2002-10-16 15:59         ` Jeff Garzik
2002-10-17  8:05           ` Joe Thornber
2002-10-17  8:26             ` Andi Kleen
2002-10-17  8:50               ` Joe Thornber
2002-10-17 16:54                 ` Jeff Garzik
2002-10-18 11:38                   ` Jakob Oestergaard [this message]
2002-10-17 15:10               ` Jeff Garzik
2002-10-18  0:48                 ` Andi Kleen
2002-10-17  0:46         ` Greg KH

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=20021018113806.GD7875@unthought.net \
    --to=jakob@unthought.net \
    --cc=ak@muc.de \
    --cc=jgarzik@pobox.com \
    --cc=joe@fib011235813.fsnet.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    /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