linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: linux-scsi <linux-scsi@vger.kernel.org>, open-osd <osd-dev@open-osd.org>
Subject: Re: [PATCH 1/3] libosd: osd_dev_info: Unique Identification of an OSD device
Date: Sun, 27 Sep 2009 10:13:28 +0200	[thread overview]
Message-ID: <4ABF1EA8.3020000@panasas.com> (raw)
In-Reply-To: <4AB21D55.9040000@panasas.com>

On 09/17/2009 02:28 PM, Boaz Harrosh wrote:
> On 09/16/2009 08:47 PM, James Bottomley wrote:
>>> +		sprintf(dev_str, "/dev/osd%d", i);
>>
>> Embedding specific forms user device paths into the kernel really looks
>> wrong here ... why are you doing this?  What happens if the user uses
>> udev to give them different names?
>>
> Two things
> 
> [1]
> These names are created here below, exactly as shown. Now udev usually
> creates more links and soft-links, I've never seen a delete?
> (I agree that maybe a comment or a define could help readability as this
>  format string is repeated twice, though slightly different).
> Lets say that "udev can do anything but not delete the primary file created
> by Kernel", as a prerequisite.
> 
> [2]
> I could easily just add a global device list, like all the other parts of
> the Kernel are trigger happy to shoot this problem.
> But I hate it.
> All these devices are already held on a Kernel structure called the name_space.
> The life_time rules, locking, reference counting, and visibility, is bug-free and
> tried out to the bone. Why should I have to reinvent the wheel? Why introduce all
> these subtle corner cases, and sleepless debugging nights?
> 
> The way I see it Kernel keeps my devices for me and gives me a "Key" to fetch for
> them. The key is the name.
> 
> That said. I'll do what people want, it is 5 minutes to put all these on a global
> list_head. It's not lack of effort on my part.
> 

I'm resending the same patch with minor changes:
1. Same defined format-string is now used both at creation of device
   and at look-up, so it is clear that these must and are the same.
2. I've added a comment to osduld_info_lookup that documents it's behavior
   So it should be clear from the get go and there are no surprises.

I'm using this code for a long time now, under a pNFS setups, and what can
I say, it does the job. 
Also I like the fact that I can use the same code as osduld_path_lookup()
and open a file handle on the device, which solved some bugs in the past.

Please consider for inclusion.

The other two trivial patches are independent please include those as well.

(I'll post as ver2 in reply to original patch)

Thanks
Boaz

  reply	other threads:[~2009-09-27  8:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-07 11:25 osd patches for the v2.6.32 merge window Boaz Harrosh
2009-09-07 11:26 ` [PATCH 1/3] libosd: osd_dev_info: Unique Identification of an OSD device Boaz Harrosh
2009-09-16 17:47   ` James Bottomley
2009-09-17 11:28     ` Boaz Harrosh
2009-09-27  8:13       ` Boaz Harrosh [this message]
2009-09-27  8:14   ` [PATCH 1/3 version 2] " Boaz Harrosh
2009-09-07 11:26 ` [PATCH 2/3] libosd: osd_dev_is_ver1 - Minor API cleanup Boaz Harrosh
2009-09-07 11:27 ` [PATCH 3/3] libosd: osd_sense: OSD_CFO_PERMISSIONS Boaz Harrosh

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=4ABF1EA8.3020000@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=osd-dev@open-osd.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;
as well as URLs for NNTP newsgroup(s).