All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Cc: "Richard Weinberger" <richard@nod.at>,
	linux-mtd@lists.infradead.org,
	"Guido Martínez" <guido@vanguardiasur.com.ar>
Subject: Re: [PATCH] ubiblock: Support UBI volume name or volume ID parameter passing
Date: Mon, 28 Jul 2014 19:31:11 +0300	[thread overview]
Message-ID: <1406565071.23376.44.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <20140721205306.GA24056@arch.cereza>

On Mon, 2014-07-21 at 17:53 -0300, Ezequiel Garcia wrote:
> Sorry for the delay on this one.
> 
> On 14 Apr 01:42 PM, Artem Bityutskiy wrote:
> > On Thu, 2014-04-10 at 11:43 -0300, Ezequiel Garcia wrote:
> > > +static int ubi_open_volume_by_id(libubi_t desc, const char *node, int vol_id, int mode)
> > >  {
> > > +       char file[256];
> > > +       struct ubi_dev_info dev_info;
> > >         int err, fd;
> > > -       libubi_t libubi;
> > >  
> > > -       err = parse_opt(argc, argv);
> > > +       err = ubi_get_dev_info(desc, node, &dev_info);
> > >         if (err)
> > > +               return errmsg("cannot get information about UBI device \"%s\"", node);
> > > +
> > > +       sprintf(file, "/dev/ubi%d_%d", dev_info.dev_num, vol_id);
> > 
> > Device node names may ve anything. Please, do not rely on the "/dev/ubi%
> > d_%d" naming scheme in the tool.
> > 
> > I think device node can be found out by scanning "/dev" and looking at
> > the device node major/minor numbers. This is more work of course.
> > 
> 
> Yeah, but the UBI major is allocated dynamically so we can't rely on that.
> We would have to call an ioctl on each /dev device, which seems like a bit
> heavy to me.
> 
> How about scanning out the sysfs and associate a name to the UBI device
> and volume ID?

What I meant is that you have these:

/sys/class/ubi/ubiX/dev

and these

/sys/class/ubi/ubiX/ubiX_Y/dev

containing the "major:minor" pairs.

For for any X:Y you can find major:minor. Then you scan "/dev" and find
the device nodes, if they exist. If they do not exist, you may ask the
user to create a device node with these major:minor in your error
message.


-- 
Best Regards,
Artem Bityutskiy

  reply	other threads:[~2014-07-28 16:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-10 14:43 [PATCH] ubiblock: Support UBI volume name or volume ID parameter passing Ezequiel Garcia
2014-04-14 10:42 ` Artem Bityutskiy
2014-04-14 18:45   ` Ezequiel Garcia
2014-07-21 20:53   ` Ezequiel Garcia
2014-07-28 16:31     ` Artem Bityutskiy [this message]
2014-07-30 14:22       ` Ezequiel Garcia

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=1406565071.23376.44.camel@sauron.fi.intel.com \
    --to=dedekind1@gmail.com \
    --cc=ezequiel.garcia@free-electrons.com \
    --cc=guido@vanguardiasur.com.ar \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    /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.