public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: jassi brar <jassi_singh_brar@yahoo.com>
To: andi@firstfloor.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: An idea .... with code
Date: Tue, 26 Aug 2008 19:27:56 -0700 (PDT)	[thread overview]
Message-ID: <274005.57526.qm@web33202.mail.mud.yahoo.com> (raw)

Hi Andi,

Before starting i would like to point out the 'philosophy' behind the idea.

 Exceptions(special cases) make for entropy and hence complexity. Generalization keeps uniformity and hences Order and Ease.
 We can't escape 'entropy' when emulating something that it is actually not, nevertheless we can minimize it by introducing as least and as localized changes as possible. 
 My idea congregates only determining changes at the lowest level(driver), unlike the respectable LOOP driver which hardcodes limits and adds to the entropy(new ioctls, special utilities etc). I am sure you, being a vetran, understand the point well.
 
 I am not for discarding features from the system, but for implementing them in a way that is lesser intrusive.
 
> Can you please expand a bit why you think losetup is that complicated
> and what the problem is with it?
 Sir, i don't object to losetup as such. It is a utility made(specifically?) for LOOP devices: which implements unnecessary gears and switches to operate.
 I object only to what could be done without using ioctls and not to features that losetup provides for devices other than Loop(are there any?)

> AFAIK you're essentially just moving a minimal version of losetup
> (with missing features like no offsets etc.) into the kernel 
 Its simpler than that :)
 All i do is implement non-ioctl method to load/unload a file as a (emulated)block device. And alloc/free resources for them on need basis rather than limiting them at driver-module load-time.

 Further about some features of LOOP drivers like encryption: i think they are better done at filesystem level.
 I believe any operation that could be done on a real block device shud be possible on an emulated one. And exactly that.
 If there is any need to do some stuff(offsets, encryption etc) then that cud be done on a real block and we would surely already have utilities for doing that on real devices(and hences on a transparent emulated device).
 I am unable to think of something practical that can _only_ be done using the 'offset feature' of losetup on /dev/loop AND which can not be accomplished for (emulated or not)block devices.
 The point is to only make least intrusive and most generic code, for making easy the inheritance of standard system-wide features, utilities and usages.

 LOOP driver was a brilliant idea for the early days of Linux. The days when one could relatively easily define new syscalls/ioctls.
 
> Or rather if you start with losetup, why stop at mount, modprobe, ifconfig, mkfs, fsck, ls[1], ...?
 I am not starting with any application.
 I start with removing redundancy in a driver(LOOP), if by doing that i make obsolete an application... am for it.

>[1] I'm sure someone could come up with some scheme to do ls using sysfs 
> and you could find someone on this list who said "cool" :)
 It would indeed be cool if the one doesn't make use of 'cat' 'grep' et al and the method is more efficient. 
 Otherwise it would just be four motobikes tugging a car :)

Regards,
Jassi



      

             reply	other threads:[~2008-08-27  2:28 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-27  2:27 jassi brar [this message]
  -- strict thread matches above, loose matches on Subject: below --
2008-08-27  0:44 An idea .... with code jassi brar
2008-08-24  8:53 jassi brar
2008-08-25 12:22 ` Jochen Voß
2008-08-25 20:53   ` Marcin Slusarz
2008-08-26  2:47 ` Bill Davidsen
2008-08-26  8:24 ` Andi Kleen
2008-08-26 10:44   ` Alexey Dobriyan
2008-08-26 11:08     ` Andi Kleen
2008-08-27  7:24   ` jassi brar
2008-08-27  7:47     ` Andi Kleen
2008-08-27  9:57       ` David Newall
2008-08-27 10:01         ` Andi Kleen
2008-08-27 12:38       ` jassi brar
2008-08-27 12:47         ` Andi Kleen
2008-08-27 14:49           ` Kasper Sandberg
2008-08-27 15:02             ` Andi Kleen
2008-08-28  1:24               ` jassi brar
2008-08-28  9:41               ` Kasper Sandberg
2008-08-30  2:57             ` Bill Davidsen

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=274005.57526.qm@web33202.mail.mud.yahoo.com \
    --to=jassi_singh_brar@yahoo.com \
    --cc=andi@firstfloor.org \
    --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