From: Artem Bityutskiy <dedekind@infradead.org>
To: Alexander Schmidt <alexs@linux.vnet.ibm.com>
Cc: linux-mtd@lists.infradead.org,
Frank Haverkamp <haver@linux.vnet.ibm.com>,
Andreas Arnez <arnez@linux.vnet.ibm.com>
Subject: Re: [PATCH 1/5] ubi-utils: introduction of libubi_common
Date: Sat, 04 Aug 2007 12:03:15 +0300 [thread overview]
Message-ID: <1186218195.26902.42.camel@sauron> (raw)
In-Reply-To: <200708021033.59483.alexs@linux.vnet.ibm.com>
Hi Alex,
On Thu, 2007-08-02 at 10:33 +0200, Alexander Schmidt wrote:
> On Saturday 28 July 2007, Artem Bityutskiy wrote:
> > Is it possible to make any patterns like this part of _utilities_?
> > UBI devices may have any names and it is defined by udev. The
> > library should not assume any UBI device name.
> >
> > Whole this file should be out of libubi,not part of it.
>
> I think this issue is caused by the command line interface we have at
> the moment, where only device numbers are specified and a path
> to a custom device cannot be specified.
Right, and I think it is trivial to add one more parameter to the
tools's cli - device node name.
> So even if we move this
> hardcoded path to the utils, the user is still not able to specify a
> custom device path in _any_ of the utils.
Just improve cli then or leave this hardcoded in the tools.
> What we have to do to resolve this issue IMO is to change the cli
> (while preserving the old one for legacy), which is a more intrusive
There is nothing intrusive actually, it is just simple parameter
addition. It is really easy.
> However, even this change seems easier to me
> when the device path is hardcoded only in one place...
Alex, it is not really easier. And it is actually silly. Look at this
lububi_common.c, look at the functions. All functions are tiny wrappers
over a libc call:
Just look again at what you sent:
+int ubi_vol_open(int devn, int vol_id, int flags)
+{
+ char path[MAXPATH];
+ int fd;
+
+ snprintf(path, MAXPATH, DEFAULT_VOL_PATTERN, devn, vol_id);
+
+ fd = open(path, flags);
+
+ return fd;
+}
+
+int ubi_vol_close(int vol_fd)
+{
+ return close(vol_fd);
+}
And these are library calls. Users are able to call open() themselves.
And close() too. No need to wrap that at all. It does not worth it
to add library interfaces for these tiny things. Similar to other
functions in that file.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
next prev parent reply other threads:[~2007-08-04 9:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-27 15:23 [PATCH 0/5] ubi-utils: migrate to new libubi Alexander Schmidt
2007-07-27 15:28 ` [PATCH 1/5] ubi-utils: introduction of libubi_common Alexander Schmidt
2007-07-28 12:51 ` Artem Bityutskiy
2007-08-02 8:33 ` Alexander Schmidt
2007-08-04 9:03 ` Artem Bityutskiy [this message]
2007-07-27 15:29 ` [PATCH 2/5] ubi-utils: migrate pddcustomize Alexander Schmidt
2007-07-27 15:30 ` [PATCH 3/5] ubi-utils: migrate ubimirror Alexander Schmidt
2007-07-27 15:31 ` [PATCH 4/5] ubi-utils: migrate pfiflash Alexander Schmidt
2007-07-27 15:31 ` [PATCH 5/5] ubi-utils: remove dead code Alexander Schmidt
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=1186218195.26902.42.camel@sauron \
--to=dedekind@infradead.org \
--cc=alexs@linux.vnet.ibm.com \
--cc=arnez@linux.vnet.ibm.com \
--cc=haver@linux.vnet.ibm.com \
--cc=linux-mtd@lists.infradead.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