[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [libarchive-discuss] mtree(8) keyword clarification: "device"
On Sep 2, 2013, at 7:09 AM, Jean-Yves Migeon
> Hi lists,
> I am actually working on making libarchive's mtree format and our NetBSD's
> mtree(8) interchangeable,
> but I am facing a documentation issue that dates back /a priori/ to 2001, and
> that concerns the "device" keyword. Copy paste from NetBSD's mtree(8):
> device The device number to use for block or char file types.
> The argument must be one of the following forms:
> A device with major and minor fields, for an
> operating system specified with format. See below
> for valid formats.
> A device with major, unit, and subunit fields, for
> an operating system specified with format.
> (Currently this is only supported by the bsdos
> Opaque number (as stored on the file system).
> The following values for format are recognized: native,
> 386bsd, 4bsd, bsdos, freebsd, hpux, isc, linux, netbsd,
> osf1, sco, solaris, sunos, svr3, svr4, and ultrix.
> The actual implementation in C never goes beyond the point of printing (long
> long)st_rdev from stat(2) in %llx, and use it "as-is" for mknod(8).
> Libarchive does it differently and log it as "device=native,<major>,<minor>"
Libarchive's mtree support has evolved quite a bit in order to
try to be more compatible with other implementations. We're
happy to get help in continuing to improve this.
I believe the current code was heavily influenced by the FreeBSD
implementation of mtree(8), which is a little different from NetBSD's
> Questions arise:
> - what was the intent of this keyword, especially the format part? mtree(8)
> was expected to receive some kind of "-k device=netbsd" parameter? Or does it
> only specify the argument of the resulting mtree evaluation?
I don't know the history; digging through source control history
might suggest something.
> - the actual code in libarchive does not follow NetBSD's format, it prints
> "device" by default as "native,<major>,<minor>". Would it be acceptable for
> libarchive to accept raw, opaque number with the convention that it starts
> with "Ox"?
Libarchive tries to be intelligent about handling variant formats.
We would be happy to see patches that made this more
It looks like it should be relatively simple to expand parse_device()
in libarchive/archive_read_support_format_mtree.c to handle other
formats. I would suggest first checking for the number of comma
Main Index |
Thread Index |