[PATCH 1/5] ubi-utils: introduction of libubi_common

Artem Bityutskiy dedekind at infradead.org
Sat Aug 4 05:03:15 EDT 2007


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 (Битюцкий Артём)




More information about the linux-mtd mailing list