newfs_udf(8) and wedges

[tlar...@polynum.com]

Context: in a previous thread, I had suggested that UDF was a way to
share a filesystem (in my case via an USB connected disk---umass) with,
at least Windows (probably works with Mac too and others, due to the
nature of UDF, but haven't tested).

The trick is to use a GPT header with a sole UDF partition (but,
apparently, from tests, the partition has to start at offset 2048
_sectors_ for Windows).

I had GPT'ed and formatted under Windows and NetBSD was able to read
using mount_udf(8) and the wedge.

The remaining has been attempted on 6.1.5.

I tried the reverse: setting everything on NetBSD, but it fails:

1) If I can create a GPT (need to force and possibly even to destroy
first to have sensible results) and then add a partition, I was then
unable to dkctl(8) addwedge: I needed to disconnect the disk and
reconnect so that the automatic wedge creation happens ;

2) newfs_udf(8) is using DIOCGDINFO and DISKPART that is relies AFAIU on
disklabel and is unable to deal with wedges. Trying to fake a disklabel
as a workaround lead to disaster.

Is there somewhere documentation or a code canonical example to update
an utility for wedge support?

--
Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.com/
http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de

[Christos Zoulas]

In article <2015070407...@polynum.com>, <tlar...@polynum.com> wrote:
>Context: in a previous thread, I had suggested that UDF was a way to
>share a filesystem (in my case via an USB connected disk---umass) with,
>at least Windows (probably works with Mac too and others, due to the
>nature of UDF, but haven't tested).
>
>The trick is to use a GPT header with a sole UDF partition (but,
>apparently, from tests, the partition has to start at offset 2048
>_sectors_ for Windows).
>
>I had GPT'ed and formatted under Windows and NetBSD was able to read
>using mount_udf(8) and the wedge.
>
>The remaining has been attempted on 6.1.5.
>
>I tried the reverse: setting everything on NetBSD, but it fails:
>
>1) If I can create a GPT (need to force and possibly even to destroy
>first to have sensible results) and then add a partition, I was then
>unable to dkctl(8) addwedge: I needed to disconnect the disk and
>reconnect so that the automatic wedge creation happens ;
>
>2) newfs_udf(8) is using DIOCGDINFO and DISKPART that is relies AFAIU on
>disklabel and is unable to deal with wedges. Trying to fake a disklabel
>as a workaround lead to disaster.
>
>Is there somewhere documentation or a code canonical example to update
>an utility for wedge support?

Look at the newfs (the src/sbin/newfs) code. I think that the parts
where we open a disk or file depending on the F flag and where we
get the disk geometry information can be factored out for each of
the newfs programs.

christos

[Martin Husemann]

On Sat, Jul 04, 2015 at 03:06:24PM +0000, Christos Zoulas wrote:
> Look at the newfs (the src/sbin/newfs) code. I think that the parts
> where we open a disk or file depending on the F flag and where we
> get the disk geometry information can be factored out for each of
> the newfs programs.

Hasn't this been done for -7 (and -current) already?
We also have makefs -t udf support now.

Martin

[Christos Zoulas]

On Jul 4, 5:35pm, mar...@duskware.de (Martin Husemann) wrote:
-- Subject: Re: newfs_udf(8) and wedges

| On Sat, Jul 04, 2015 at 03:06:24PM +0000, Christos Zoulas wrote:
| > Look at the newfs (the src/sbin/newfs) code. I think that the parts
| > where we open a disk or file depending on the F flag and where we
| > get the disk geometry information can be factored out for each of
| > the newfs programs.
|
| Hasn't this been done for -7 (and -current) already?
| We also have makefs -t udf support now.

look at newfs_udf.c...

christos

[tlar...@polynum.com]

On Sat, Jul 04, 2015 at 11:45:52AM -0400, Christos Zoulas wrote:
> On Jul 4, 5:35pm, mar...@duskware.de (Martin Husemann) wrote:
> -- Subject: Re: newfs_udf(8) and wedges
>

> | On Sat, Jul 04, 2015 at 03:06:24PM +0000, Christos Zoulas wrote:
> | > Look at the newfs (the src/sbin/newfs) code. I think that the parts
> | > where we open a disk or file depending on the F flag and where we
> | > get the disk geometry information can be factored out for each of
> | > the newfs programs.
> |
> | Hasn't this been done for -7 (and -current) already?
> | We also have makefs -t udf support now.
>

> look at newfs_udf.c...
>

At least it's clear that if I tackle the task, I have to start from the
-7 source since newfs_udf.c has been hugely reworked comparing from 6.x

--
Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.com/
http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

[Christos Zoulas]

On Jul 16, 7:03pm, da...@l8s.co.uk (David Laight) wrote:
-- Subject: Re: stdio buffering extension

| The one I want most is line buffering to pipes.
| You almost want to force it from the reading end (eg in tee).
| The other common case is when stdout and stderr refer to the
| same file - when you probably want line buffering for stdout.

Yes, but specifying via environment variables is saner than making
a bunch of complicated rules.

| OTOH if a program is writing binary data (maybe using fwrite()
| not fprintf()) then block buffering is more likely to be
| appropriate.

The standard does not differentiate, I think. Our code obeys the
current buffering flags.

| How much scope does the standard give for more intelligent
| choices?

Not much. I think that even the environment variables I added violate
the standard when set.

christos