All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Menon, Nishanth" <nm@ti.com>
To: Ameya Palande <ameya.palande@nokia.com>
Cc: "Ramirez Luna, Omar" <omar.ramirez@ti.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"Chitriki Rudramuni, Deepak" <deepak.chitriki@ti.com>
Subject: Re: [PATCH] DSPBRIDGE: Get rid of driver_minor global variable
Date: Tue, 2 Feb 2010 12:05:53 +0200	[thread overview]
Message-ID: <4B67F901.7010602@ti.com> (raw)
In-Reply-To: <1265104997.3068.10.camel@chotu.research.nokia.com>

Ameya Palande said the following on 02/02/2010 12:03 PM:
> Hi Nishanth,
> 
> On Mon, 2010-02-01 at 20:48 +0100, ext Menon, Nishanth wrote:
>> Ameya Palande said the following on 02/01/2010 08:18 PM:
>>> Since there is only 1 device there is no need of driver_minor global variable.
>> i am a little skeptical about this change - mainly coz, it might be a good idea for a userspace option
>> to be able to define what the minor id could be -> maybe an example could be /dev/mem which has a minor
>> id of 1, not 0. having a module_param might be better as such.. just my 2 cents..
> 
> I do not agree with user space having control of defining minor id.
> I would like to rephrase this sentence as: userspace should have control
> of defining name (string) for the device file. I guess udev takes care
> of that already!
>  
> Ideally userspace should just deal with device
> names: /dev/device1, /dev/device2 etc. Why it interprets (and that way
> creates a dependency on) major/minor number?
> 
> I am in favor of saving 4 bytes and less global namespace pollution :)
> 
> /dev/mem has minor id of 1 because it shares its major id with ramdisk.
> 
> file: include/linux/major.h
> 
> #define MEM_MAJOR               1
> #define RAMDISK_MAJOR           1
> 
> Cheers,
> Ameya.
> 
ok ok ok. you have me convinced :D

/me slinks away to the corner of the room and sits on the chair facing 
the wall ;)

Regards,
Nishanth Menon

  reply	other threads:[~2010-02-02 10:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-01 18:18 [PATCH] DSPBRIDGE: Get rid of driver_minor global variable Ameya Palande
2010-02-01 19:48 ` Menon, Nishanth
2010-02-02 10:03   ` Ameya Palande
2010-02-02 10:05     ` Menon, Nishanth [this message]
2010-02-06  1:58 ` Omar Ramirez Luna

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=4B67F901.7010602@ti.com \
    --to=nm@ti.com \
    --cc=ameya.palande@nokia.com \
    --cc=deepak.chitriki@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=omar.ramirez@ti.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.