Re: CVS commit: src/sbin/gpt

2023-09-27 Thread Robert Elz
Date:Wed, 27 Sep 2023 09:44:10 +
From:"Taylor R Campbell" 
Message-ID:  <20230927094410.b9257f...@cvs.netbsd.org>

  | gpt(8): Make gpt type array and enum match again.

Thanks, and apologies for not checking that better - I did test
that it recognised the new one properly...

kre




Re: CVS commit: src/sbin/gpt

2019-06-25 Thread Christos Zoulas
In article <201906250354.x5p3suvz009...@server.cornerstoneservice.ca>,
John Nemeth   wrote:
>On Jun 25,  3:42am, "John Nemeth" wrote:
>} 
>} Module Name: src
>} Committed By:jnemeth
>} Date:Tue Jun 25 03:42:46 UTC 2019
>} 
>} Modified Files:
>}  src/sbin/gpt: gpt.h
>} 
>} Log Message:
>} gpt.c
>
> ARGH!  Message should have read:
>
>Add gpt_change_hdr() similar to gpt_change_ent() for changing
>arbitrary header fields.
>
>Updated in repository.

If you did, then the git sync is broken :-( I guess it is time to turn
off "cvs admin -m"...

christos



Re: CVS commit: src/sbin/gpt

2019-06-24 Thread John Nemeth
On Jun 25,  3:42am, "John Nemeth" wrote:
} 
} Module Name:  src
} Committed By: jnemeth
} Date: Tue Jun 25 03:42:46 UTC 2019
} 
} Modified Files:
}   src/sbin/gpt: gpt.h
} 
} Log Message:
} gpt.c

 ARGH!  Message should have read:

Add gpt_change_hdr() similar to gpt_change_ent() for changing
arbitrary header fields.

Updated in repository.

}-- End of excerpt from "John Nemeth"


Re: CVS commit: src/sbin/gpt

2017-02-13 Thread David Laight
On Sun, Feb 12, 2017 at 06:20:53PM +, Christos Zoulas wrote:
> In article <87bmu7l1k6@free.fr>,
> Aymeric Vincent   wrote:
> >chris...@astron.com (Christos Zoulas) writes:
> >
> >> Yes, doesn't libcompat provide our getopt()? Or are you trying to compile
> >> this standalone?
> >
> >It does, but from what I understand, we replace only getopt_long()
> >unconditionnally and use the host's getopt() if the optind variable can
> >be linked against.
> >
> >Confirmed on a Linux host in /lib:
> >
> >$ nm libnbcompat.a | grep getopt
> >getopt_long.lo:
> >0098 T __nbcompat_getopt_long
> >$ 
> >
> >I agree it would be nicer to use always our getopt().
> 
> Yes, because the glibc is not posix compliant by default.

More than non-compliaint, completely f*cked.
It reorders argv[] to move all 'options' before filenames.
So 'foo bar -baz' is changed to 'foo -baz bar' before being processed.
I've NFI of the justification for it.
Historically you could do 'rlogin host -l username' but I
don't know of any others.

David

-- 
David Laight: da...@l8s.co.uk


Re: CVS commit: src/sbin/gpt

2017-02-12 Thread Christos Zoulas
In article <87bmu7l1k6@free.fr>,
Aymeric Vincent   wrote:
>chris...@astron.com (Christos Zoulas) writes:
>
>> Yes, doesn't libcompat provide our getopt()? Or are you trying to compile
>> this standalone?
>
>It does, but from what I understand, we replace only getopt_long()
>unconditionnally and use the host's getopt() if the optind variable can
>be linked against.
>
>Confirmed on a Linux host in /lib:
>
>$ nm libnbcompat.a | grep getopt
>getopt_long.lo:
>0098 T __nbcompat_getopt_long
>$ 
>
>I agree it would be nicer to use always our getopt().

Yes, because the glibc is not posix compliant by default.

christos



Re: CVS commit: src/sbin/gpt

2017-02-12 Thread Aymeric Vincent
chris...@astron.com (Christos Zoulas) writes:

> Yes, doesn't libcompat provide our getopt()? Or are you trying to compile
> this standalone?

It does, but from what I understand, we replace only getopt_long()
unconditionnally and use the host's getopt() if the optind variable can
be linked against.

Confirmed on a Linux host in /lib:

$ nm libnbcompat.a | grep getopt
getopt_long.lo:
0098 T __nbcompat_getopt_long
$ 

I agree it would be nicer to use always our getopt().

 Aymeric


Re: CVS commit: src/sbin/gpt

2017-02-12 Thread Christos Zoulas
In article <20170212165406.79987f...@cvs.netbsd.org>,
Aymeric Vincent  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  aymeric
>Date:  Sun Feb 12 16:54:06 UTC 2017
>
>Modified Files:
>   src/sbin/gpt: main.c
>
>Log Message:
>Make gpt(8) work when compiled on a glibc-based OS.
>
>This restores the ability to build amd64 install-image's under Linux.

Yes, doesn't libcompat provide our getopt()? Or are you trying to compile
this standalone?

christos



Re: CVS commit: src/sbin/gpt

2016-06-09 Thread Christos Zoulas
In article <201606091738.u59hcf6c007...@server.cornerstoneservice.ca>,
John Nemeth   wrote:
>On Jun 9, 11:12am, "Christos Zoulas" wrote:
>} 
>} Module Name: src
>} Committed By:christos
>} Date:Thu Jun  9 15:12:54 UTC 2016
>} 
>} Modified Files:
>}  src/sbin/gpt: biosboot.c create.c gpt.8 gpt.c gpt.h migrate.c show.c
>} 
>} Log Message:
>} PR/51230: Add the ability to set the active flag in the PMBR.
>
> I would have just set the active flag in biosboot always since
>it is unlikely to cause problems.  Also, I would not have bothered
>with adding the ability to set the active flag to create and migrate,
>since without running biosboot the disk won't be legacy bootable
>anyways, so there is no point.  Not clearing the active flag in
>gpt_create_pmbr_part() was likely a bug.

So no flags, just make the PMBR active is biosboot is called. When do
you clear it?

christos



Re: CVS commit: src/sbin/gpt

2016-06-09 Thread John Nemeth
On Jun 9, 11:12am, "Christos Zoulas" wrote:
} 
} Module Name:  src
} Committed By: christos
} Date: Thu Jun  9 15:12:54 UTC 2016
} 
} Modified Files:
}   src/sbin/gpt: biosboot.c create.c gpt.8 gpt.c gpt.h migrate.c show.c
} 
} Log Message:
} PR/51230: Add the ability to set the active flag in the PMBR.

 I would have just set the active flag in biosboot always since
it is unlikely to cause problems.  Also, I would not have bothered
with adding the ability to set the active flag to create and migrate,
since without running biosboot the disk won't be legacy bootable
anyways, so there is no point.  Not clearing the active flag in
gpt_create_pmbr_part() was likely a bug.

}-- End of excerpt from "Christos Zoulas"


Re: CVS commit: src/sbin/gpt

2015-12-02 Thread Robert Elz
Date:Wed, 2 Dec 2015 07:36:53 -0500
From:"Christos Zoulas" 
Message-ID:  <20151202123653.7531...@cvs.netbsd.org>

  | Modified Files:
  | src/sbin/gpt: backup.c gpt.8 restore.c
  | 
  | Log Message:
  | Allow backup and restore to operate on files.

Will that modified code still (really) support writing to stdout?
The man page suggests it should, but I don't see how the code can.

kre



Re: CVS commit: src/sbin/gpt

2015-12-02 Thread Christos Zoulas
In article <28433.1449088...@andromeda.noi.kre.to>,
Robert Elz   wrote:
>Date:Wed, 2 Dec 2015 07:36:53 -0500
>From:"Christos Zoulas" 
>Message-ID:  <20151202123653.7531...@cvs.netbsd.org>
>
>  | Modified Files:
>  |src/sbin/gpt: backup.c gpt.8 restore.c
>  | 
>  | Log Message:
>  | Allow backup and restore to operate on files.
>
>Will that modified code still (really) support writing to stdout?
>The man page suggests it should, but I don't see how the code can.

"/dev/stdout".

christos



Re: CVS commit: src/sbin/gpt

2015-12-02 Thread Christos Zoulas
On Dec 3,  5:37am, k...@munnari.oz.au (Robert Elz) wrote:
-- Subject: Re: CVS commit: src/sbin/gpt

| Sure, but "how do write to stdout" wasn't what I asked ...
| 
|  gpt backup [-o outfile]
|  The backup command dumps the MBR or (PMBR) and GPT partition
|  tables to standard output or to a file specified by the outfile
|  argument in a format to be used by the restore command.  The
|  format is a plist.  It should not be modified.
| 
| What I meant was, if the "-o outfile" is not there, and the dump is
| "tables to standard output" and not "or to a file specified" ...
| 
| How does that work now?
| 
| Of, if you like, take your new version, and just try "gpt backup XXXn"
| (or whatever device is relevant) and observe.

I observe data going to stdout because:

static const char *outfile = "/dev/stdout";

It does not work for you?

christos


Re: CVS commit: src/sbin/gpt

2015-12-02 Thread Robert Elz
Date:Wed, 2 Dec 2015 17:41:08 -0500
From:chris...@zoulas.com (Christos Zoulas)
Message-ID:  <20151202224108.9064b17f...@rebar.astron.com>

  | I observe data going to stdout because:
  | static const char *outfile = "/dev/stdout";

Oh yes, OK, sorry - missed that.It isn't a style I would use, so
I wasn't expecting that.   I dislike assigning to a gobal var from a
source that might come from anywhere ... in current invocation it is
from the arg list, so isstable, but someone might add an interactive
gpt mode, and then this method would break badly.

kre



Re: CVS commit: src/sbin/gpt

2015-12-02 Thread Christos Zoulas
On Dec 3,  6:54am, k...@munnari.oz.au (Robert Elz) wrote:
-- Subject: Re: CVS commit: src/sbin/gpt

| Date:Wed, 2 Dec 2015 17:41:08 -0500
| From:chris...@zoulas.com (Christos Zoulas)
| Message-ID:  <20151202224108.9064b17f...@rebar.astron.com>
| 
|   | I observe data going to stdout because:
|   | static const char *outfile = "/dev/stdout";
| 
| Oh yes, OK, sorry - missed that.It isn't a style I would use, so
| I wasn't expecting that.   I dislike assigning to a gobal var from a
| source that might come from anywhere ... in current invocation it is
| from the arg list, so isstable, but someone might add an interactive
| gpt mode, and then this method would break badly.

Yes, I am fixing those in the next pass (no static globals).

christos


Re: CVS commit: src/sbin/gpt

2015-12-01 Thread Christos Zoulas
On Dec 1,  7:13am, jnem...@cue.bc.ca (John Nemeth) wrote:
-- Subject: Re: CVS commit: src/sbin/gpt

|  Uh, what a silly question.  As you should know, gpt(8) first
| appeared in NetBSD 4.0.  NetBSD-6 has always supported gpt disks.
| My plan was to pullup everything up to the point of toolification
| to netbsd-6.  However, some useful changes have been made since
| then which should also be pulled up.  These changes will likely
| have to be pulled up by patch now.  Even if the new ioctls are
| pulled up to netbsd-6, I would prefer gpt(8) to be able to use the
| older methods, since that doesn't need a kernel upgrade.

Yes, and still the majority of people are not using it because it
is not supported in sysinst, and the kernel/userland support for
wedges in 6 is lacking. You need to be an expert to be able to
use it before 7.

You have to make choices to move ahead; you can keep tons of
backwards compatibility code around (which is conditionally compiled
and not well tested), or you can cleanup the code and make it better
managed and testable for the future.

christos


Re: CVS commit: src/sbin/gpt

2015-11-30 Thread John Nemeth
On Nov 30,  4:58pm, John Nemeth wrote:
}
}  See question in gpt.c (and others).
} 
} On Nov 30,  2:59pm, "Christos Zoulas" wrote:
} }
} } This is a multi-part message in MIME format.
} } 
} } --_--=_1448913574208280
} } Content-Disposition: inline
} } Content-Transfer-Encoding: 8bit
} } Content-Type: text/plain; charset="US-ASCII"
} } 
} } Module Name:src
} } Committed By:   christos
} } Date:   Mon Nov 30 19:59:34 UTC 2015
} } 
} } Modified Files:
} } src/sbin/gpt: Makefile add.c gpt.8 gpt.c gpt.h resize.c
} } Added Files:
} } src/sbin/gpt: main.c
} } 
} } Log Message:
} } - automatically sync the wedge information unless -n is specified.
} } - document the general options in the traditional way.
} } - split the main program into a separate file.
} } 
} } 
} } To generate a diff of this commit:
} } cvs rdiff -u -r1.15 -r1.16 src/sbin/gpt/Makefile
} } cvs rdiff -u -r1.28 -r1.29 src/sbin/gpt/add.c
} } cvs rdiff -u -r1.37 -r1.38 src/sbin/gpt/gpt.8
} } cvs rdiff -u -r1.45 -r1.46 src/sbin/gpt/gpt.c
} } cvs rdiff -u -r1.21 -r1.22 src/sbin/gpt/gpt.h
} } cvs rdiff -u -r0 -r1.1 src/sbin/gpt/main.c
} } cvs rdiff -u -r1.12 -r1.13 src/sbin/gpt/resize.c
} } 
} } Please note that diffs are not public domain; they are subject to the
} } copyright notices on the relevant files.
} } 
} } 
} } --_--=_1448913574208280
} } Content-Disposition: inline
} } Content-Length: 17047
} } Content-Transfer-Encoding: binary
} } Content-Type: text/x-diff; charset=us-ascii
} } 
} } Modified files:
} } 
} } Index: src/sbin/gpt/gpt.c
} } diff -u src/sbin/gpt/gpt.c:1.45 src/sbin/gpt/gpt.c:1.46
} } --- src/sbin/gpt/gpt.c:1.45 Sun Nov 29 09:03:35 2015
} } +++ src/sbin/gpt/gpt.c  Mon Nov 30 14:59:34 2015
} } @@ -35,7 +35,7 @@
} }  __FBSDID("$FreeBSD: src/sbin/gpt/gpt.c,v 1.16 2006/07/07 02:44:23 marcel 
Exp $");
} }  #endif
} }  #ifdef __RCSID
} } -__RCSID("$NetBSD: gpt.c,v 1.45 2015/11/29 14:03:35 christos Exp $");
} } +__RCSID("$NetBSD: gpt.c,v 1.46 2015/11/30 19:59:34 christos Exp $");
} }  #endif
} }  
} }  #include 
} } @@ -68,7 +68,9 @@ off_t mediasz;
} }  u_int  parts;
} }  u_int  secsz;
} }  
} } -intreadonly, verbose, quiet;
} } +intreadonly, verbose, quiet, nosync;
} } +
} } +static int modified;
} }  
} }  static uint32_t crc32_tab[] = {
} } 0x, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419, 0x706af48f,
} } @@ -269,10 +271,11 @@ gpt_write(int fd, map_t *map)
} }  
} } count = map->map_size * secsz;
} } ofs = map->map_start * secsz;
} } -   if (lseek(fd, ofs, SEEK_SET) == ofs &&
} } -   write(fd, map->map_data, count) == (ssize_t)count)
} } -   return (0);
} } -   return (-1);
} } +   if (lseek(fd, ofs, SEEK_SET) != ofs ||
} 
}  Why did you change the "&&" to "||"?  If the lseek() fails,
} you will now be writing data to the wrong place on the disk.

 Never mind, I just looked at it again.  Of course, if the
lseek() fails, the whole expression is true, and short circuiting
rules apply.

} } +   write(fd, map->map_data, count) != (ssize_t)count)
} } +   return -1;
} } +   modified = 1;
} } +   return 0;
} }  }
} }  
} }  static int
} } 
} } --_--=_1448913574208280--
} } 
} }-- End of excerpt from "Christos Zoulas"
}-- End of excerpt from John Nemeth


Re: CVS commit: src/sbin/gpt

2015-11-30 Thread Christos Zoulas
In article <201512010058.tb10wtzj029...@server.cornerstoneservice.ca>,
John Nemeth   wrote:
> See question in gpt.c (and others).
>
>} -printf("Partition %d added, use:\n", i + 1);
>} -printf("\tdkctl %s addwedge  %" PRIu64 " %" PRIu64
>} -" \n", device_arg, map->map_start, map->map_size);
>} -printf("to create a wedge for it\n");
>} +printf("Partition %d added on %s: ", i + 1, device_arg);
>} +printf("%s %" PRIu64 " %" PRIu64 "\n", type, map->map_start,
>} +map->map_size);
>
> This message needs to depend on the new -n flag, otherwise it
>may give incorrect information.

I will add a message to clarify that thanks!

>} @@ -269,10 +271,11 @@ gpt_write(int fd, map_t *map)
>}  
>}  count = map->map_size * secsz;
>}  ofs = map->map_start * secsz;
>} -if (lseek(fd, ofs, SEEK_SET) == ofs &&
>} -write(fd, map->map_data, count) == (ssize_t)count)
>} -return (0);
>} -return (-1);
>} +if (lseek(fd, ofs, SEEK_SET) != ofs ||
>
> Why did you change the "&&" to "||"?  If the lseek() fails,
>you will now be writing data to the wrong place on the disk.

Nope, I flipped the polarity of the tests too.

>
>} +write(fd, map->map_data, count) != (ssize_t)count)
>} +return -1;
>} +modified = 1;
>} +return 0;

christos



Re: CVS commit: src/sbin/gpt

2015-11-30 Thread John Nemeth
On Nov 30,  9:03pm, "Christos Zoulas" wrote:
}
} This is a multi-part message in MIME format.
} 
} --_--=_1448935435147560
} Content-Disposition: inline
} Content-Transfer-Encoding: 8bit
} Content-Type: text/plain; charset="US-ASCII"
} 
} Module Name:  src
} Committed By: christos
} Date: Tue Dec  1 02:03:55 UTC 2015
} 
} Modified Files:
}   src/sbin/gpt: add.c gpt.c resize.c
} 
} Log Message:
} - use gpt_msg to print informational messages (perhaps these should be printed
}   only with -v)
} - don't print any messages with gpt_msg if quiet
} - print a message if we didn't reconfigure the wedges
} 
} 
} To generate a diff of this commit:
} cvs rdiff -u -r1.29 -r1.30 src/sbin/gpt/add.c
} cvs rdiff -u -r1.47 -r1.48 src/sbin/gpt/gpt.c
} cvs rdiff -u -r1.13 -r1.14 src/sbin/gpt/resize.c
} 
} Please note that diffs are not public domain; they are subject to the
} copyright notices on the relevant files.
} 
} 
} --_--=_1448935435147560
} Content-Disposition: inline
} Content-Length: 2767
} Content-Transfer-Encoding: binary
} Content-Type: text/x-diff; charset=us-ascii
} 
} Modified files:
} 
} Index: src/sbin/gpt/gpt.c
} diff -u src/sbin/gpt/gpt.c:1.47 src/sbin/gpt/gpt.c:1.48
} --- src/sbin/gpt/gpt.c:1.47   Mon Nov 30 20:49:23 2015
} +++ src/sbin/gpt/gpt.cMon Nov 30 21:03:55 2015
} @@ -573,15 +573,22 @@ void
}  gpt_close(int fd)
}  {
}  
} - if (modified && !nosync) {
} + if (!modified)
} + goto out;
} +
} + if (!nosync) {
}  #ifdef DIOCMWEDGES
}   int bits;
}   if (ioctl(fd, DIOCMWEDGES, ) == -1)
}   warn("Can't update wedge information");
} + else
} + goto out;
}  #endif
}   }
} + gpt_msg("You need to run \"dkctl %s makewedges\""
} + " for the changes to take effect\n", device_name);

 dkctl makewedges is just ioctl(DIOCMWEDGES), so if DIOCMWEDGES
doesn't exist or it fails, then dkctl makewedges won't do anything,
which means that the user would either need to use dkctl add, etc.,
or reboot.

}  
} - /* XXX post processing? */
} +out:
}   close(fd);
}  }
}  
} --_--=_1448935435147560--
} 
}-- End of excerpt from "Christos Zoulas"


Re: CVS commit: src/sbin/gpt

2015-11-30 Thread John Nemeth
 See question in gpt.c (and others).

On Nov 30,  2:59pm, "Christos Zoulas" wrote:
}
} This is a multi-part message in MIME format.
} 
} --_--=_1448913574208280
} Content-Disposition: inline
} Content-Transfer-Encoding: 8bit
} Content-Type: text/plain; charset="US-ASCII"
} 
} Module Name:  src
} Committed By: christos
} Date: Mon Nov 30 19:59:34 UTC 2015
} 
} Modified Files:
}   src/sbin/gpt: Makefile add.c gpt.8 gpt.c gpt.h resize.c
} Added Files:
}   src/sbin/gpt: main.c
} 
} Log Message:
} - automatically sync the wedge information unless -n is specified.
} - document the general options in the traditional way.
} - split the main program into a separate file.
} 
} 
} To generate a diff of this commit:
} cvs rdiff -u -r1.15 -r1.16 src/sbin/gpt/Makefile
} cvs rdiff -u -r1.28 -r1.29 src/sbin/gpt/add.c
} cvs rdiff -u -r1.37 -r1.38 src/sbin/gpt/gpt.8
} cvs rdiff -u -r1.45 -r1.46 src/sbin/gpt/gpt.c
} cvs rdiff -u -r1.21 -r1.22 src/sbin/gpt/gpt.h
} cvs rdiff -u -r0 -r1.1 src/sbin/gpt/main.c
} cvs rdiff -u -r1.12 -r1.13 src/sbin/gpt/resize.c
} 
} Please note that diffs are not public domain; they are subject to the
} copyright notices on the relevant files.
} 
} 
} --_--=_1448913574208280
} Content-Disposition: inline
} Content-Length: 17047
} Content-Transfer-Encoding: binary
} Content-Type: text/x-diff; charset=us-ascii
} 
} Modified files:
} 
} Index: src/sbin/gpt/add.c
} diff -u src/sbin/gpt/add.c:1.28 src/sbin/gpt/add.c:1.29
} --- src/sbin/gpt/add.c:1.28   Sat Nov 28 19:14:46 2015
} +++ src/sbin/gpt/add.cMon Nov 30 14:59:34 2015
} @@ -33,7 +33,7 @@
}  __FBSDID("$FreeBSD: src/sbin/gpt/add.c,v 1.14 2006/06/22 22:05:28 marcel Exp 
$");
}  #endif
}  #ifdef __RCSID
} -__RCSID("$NetBSD: add.c,v 1.28 2015/11/29 00:14:46 christos Exp $");
} +__RCSID("$NetBSD: add.c,v 1.29 2015/11/30 19:59:34 christos Exp $");
}  #endif
}  
}  #include 
} @@ -180,10 +180,9 @@ add(int fd)
}   gpt_write(fd, lbt);
}   gpt_write(fd, tpg);
}  
} - printf("Partition %d added, use:\n", i + 1);
} - printf("\tdkctl %s addwedge  %" PRIu64 " %" PRIu64
} - " \n", device_arg, map->map_start, map->map_size);
} - printf("to create a wedge for it\n");
} + printf("Partition %d added on %s: ", i + 1, device_arg);
} + printf("%s %" PRIu64 " %" PRIu64 "\n", type, map->map_start,
} + map->map_size);

 This message needs to depend on the new -n flag, otherwise it
may give incorrect information.

}  }
}  
}  int
} 
} Index: src/sbin/gpt/gpt.c
} diff -u src/sbin/gpt/gpt.c:1.45 src/sbin/gpt/gpt.c:1.46
} --- src/sbin/gpt/gpt.c:1.45   Sun Nov 29 09:03:35 2015
} +++ src/sbin/gpt/gpt.cMon Nov 30 14:59:34 2015
} @@ -35,7 +35,7 @@
}  __FBSDID("$FreeBSD: src/sbin/gpt/gpt.c,v 1.16 2006/07/07 02:44:23 marcel Exp 
$");
}  #endif
}  #ifdef __RCSID
} -__RCSID("$NetBSD: gpt.c,v 1.45 2015/11/29 14:03:35 christos Exp $");
} +__RCSID("$NetBSD: gpt.c,v 1.46 2015/11/30 19:59:34 christos Exp $");
}  #endif
}  
}  #include 
} @@ -68,7 +68,9 @@ off_t   mediasz;
}  u_intparts;
}  u_intsecsz;
}  
} -int  readonly, verbose, quiet;
} +int  readonly, verbose, quiet, nosync;
} +
} +static int modified;
}  
}  static uint32_t crc32_tab[] = {
}   0x, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419, 0x706af48f,
} @@ -269,10 +271,11 @@ gpt_write(int fd, map_t *map)
}  
}   count = map->map_size * secsz;
}   ofs = map->map_start * secsz;
} - if (lseek(fd, ofs, SEEK_SET) == ofs &&
} - write(fd, map->map_data, count) == (ssize_t)count)
} - return (0);
} - return (-1);
} + if (lseek(fd, ofs, SEEK_SET) != ofs ||

 Why did you change the "&&" to "||"?  If the lseek() fails,
you will now be writing data to the wrong place on the disk.

} + write(fd, map->map_data, count) != (ssize_t)count)
} + return -1;
} + modified = 1;
} + return 0;
}  }
}  
}  static int
} @@ -569,6 +572,12 @@ gpt_open(const char *dev, int flags)
}  void
}  gpt_close(int fd)
}  {
} + int bits;
} +
} + if (modified && !nosync)
} + if (ioctl(fd, DIOCMWEDGES, ) == -1)
} + warn("Can't update wedge information");
} +
}   /* XXX post processing? */
}   close(fd);
}  }
} @@ -583,172 +592,3 @@ gpt_msg(const char *fmt, ...)
}   va_end(ap);
}   printf("\n");
}  }
} -
} -static struct {
} - int (*fptr)(int, char *[]);
} - const char *name;
} -} cmdsw[] = {
} - { cmd_add, "add" },
} -#ifndef HAVE_NBTOOL_CONFIG_H
} - { cmd_backup, "backup" },
} -#endif
} - { cmd_biosboot, "biosboot" },
} - { cmd_create, "create" },
} - { cmd_destroy, "destroy" },
} - { cmd_header, "header" },
} - { NULL, "help" },
} - { cmd_label, "label" },
} - { cmd_migrate, "migrate" },
} - { cmd_recover, "recover" },
} - { cmd_remove, "remove" },
} - { NULL, "rename" },
} - { cmd_resize, "resize" },
} - { cmd_resizedisk, "resizedisk" },
} -#ifndef 

Re: CVS commit: src/sbin/gpt

2015-11-30 Thread Christos Zoulas
On Nov 29, 11:22pm, jnem...@cue.bc.ca (John Nemeth) wrote:
-- Subject: Re: CVS commit: src/sbin/gpt

|  I have read the Makefile.  I think there is confusion between
| the tool version and the crossbuilt version intended to go in the
| release being built.  Obviously, the tool version will use the
| system headers, and that may be the one that I saw fail (I don't
| have the log anymore).

The cross-built version is not affected either. In current it will just
use the ioctls and be happy. In older versions it will use what it had,
since it is not changed.

|  Maybe so, but one could just lift the source code from -current
| and plunk it on an older version of NetBSD and it would just work.
| Now, one can not do that.  Having to update the kernel for a
| relatively small userland utility is kind of annoying.

That's the only disadvantage. Even if you wanted to do this, I am
saying I would prefer that the pullup was done to the kernel to
support the missing ioctls. And we are talking only about NetBSD-6
where the utility is not that useful, since NetBSD-7 has them. Are
you really planning to support gpt disks on NetBSD-6?

christos


Re: CVS commit: src/sbin/gpt

2015-11-29 Thread John Nemeth
On Nov 29,  8:46am, "Christos Zoulas" wrote:
}
} This is a multi-part message in MIME format.
} 
} --_--=_1448804783204230
} Content-Disposition: inline
} Content-Transfer-Encoding: 8bit
} Content-Type: text/plain; charset="US-ASCII"
} 
} Module Name:  src
} Committed By: christos
} Date: Sun Nov 29 13:46:23 UTC 2015
} 
} Modified Files:
}   src/sbin/gpt: gpt.c
} 
} Log Message:
} Only use the ioctl's if we have them.

 Why did you leave out the call to getdisksize() for when the
ioctls don't exist?  Actually, why did you even bother with this
patch, since it is pretty much equivalent to what was there before,
minus the missing functionality?

} To generate a diff of this commit:
} cvs rdiff -u -r1.43 -r1.44 src/sbin/gpt/gpt.c
} 
} Please note that diffs are not public domain; they are subject to the
} copyright notices on the relevant files.
} 
} 
} --_--=_1448804783204230
} Content-Disposition: inline
} Content-Length: 1887
} Content-Transfer-Encoding: binary
} Content-Type: text/x-diff; charset=us-ascii
} 
} Modified files:
} 
} Index: src/sbin/gpt/gpt.c
} diff -u src/sbin/gpt/gpt.c:1.43 src/sbin/gpt/gpt.c:1.44
} --- src/sbin/gpt/gpt.c:1.43   Sun Nov 29 08:24:28 2015
} +++ src/sbin/gpt/gpt.cSun Nov 29 08:46:23 2015
} @@ -35,7 +35,7 @@
}  __FBSDID("$FreeBSD: src/sbin/gpt/gpt.c,v 1.16 2006/07/07 02:44:23 marcel Exp 
$");
}  #endif
}  #ifdef __RCSID
} -__RCSID("$NetBSD: gpt.c,v 1.43 2015/11/29 13:24:28 jnemeth Exp $");
} +__RCSID("$NetBSD: gpt.c,v 1.44 2015/11/29 13:46:23 christos Exp $");
}  #endif
}  
}  #include 
} @@ -486,24 +486,38 @@ gpt_open(const char *dev, int flags)
}   }
}  
}   if ((sb.st_mode & S_IFMT) != S_IFREG) {
} + if (secsz == 0) {
}  #ifdef DIOCGSECTORSIZE
} - if ((secsz == 0 && ioctl(fd, DIOCGSECTORSIZE, ) == -1) ||
} -   (mediasz == 0 && ioctl(fd, DIOCGMEDIASIZE, ) == -1)) {
} - if (!quiet)
} - warn("Cannot get sector/media size for `%s'",
} - device_name);
} - goto close;
} - }
} -#else
} - if (getdisksize(device_name, , ) == -1) {
} - if (!quiet)
} - warn("Cannot get sector/media size for `%s'",
} - device_name);
} - goto close;
} + if (ioctl(fd, DIOCGSECTORSIZE, ) == -1) {
} + if (!quiet)
} + warn("Cannot get sector size for `%s'",
} + device_name);
} + goto close;
} + }
} +#endif
} + if (secsz == 0) {
} + if (!quiet)
} + warnx("Sector size for `%s' can't be 0",
} + device_name);
} + goto close;
} + }
}   }
} + if (mediasz == 0) {
} +#ifdef DIOCGMEDIASIZE
} + if (ioctl(fd, DIOCGMEDIASIZE, ) == -1) {
} + if (!quiet)
} + warn("Cannot get media size for `%s'",
} + device_name);
} + goto close;
} + }
}  #endif
} - if (secsz == 0 || mediasz == 0)
} - errx(1, "Please specify sector/media size");
} + if (mediasz == 0) {
} + if (!quiet)
} + warnx("Media size for `%s' can't be 0",
} + device_name);
} + goto close;
} + }
} + }
}   } else {
}   if (secsz == 0)
}   secsz = 512;/* Fixed size for files. */
} 
} 
} --_--=_1448804783204230--
} 
}-- End of excerpt from "Christos Zoulas"




Re: CVS commit: src/sbin/gpt

2015-11-29 Thread Christos Zoulas
In article <201511291418.tateiwrt002...@server.cornerstoneservice.ca>,
John Nemeth   wrote:
>
> Why did you leave out the call to getdisksize() for when the
>ioctls don't exist?  Actually, why did you even bother with this
>patch, since it is pretty much equivalent to what was there before,
>minus the missing functionality?

Because who has this functionality (drvctl) and does not have the
ioctls? Only the NetBSD-6 tools build. This is too much complexity
for very little benefit. It is simpler to add the ioctls to NetBSD-6
than keeping all this messy libprop code around (which we have again
in fsck...) :-)

christos



Re: CVS commit: src/sbin/gpt

2015-11-29 Thread John Nemeth
On Nov 29,  8:24pm, Christos Zoulas wrote:
} On Nov 29,  5:01pm, jnem...@cue.bc.ca (John Nemeth) wrote:
} 
} |  The reason I noticed it was due to a build failure.  The system
} | I was building it on is:
} | 
} | NetBSD msgate 7.0_BETA NetBSD 7.0_BETA (GENERIC.201408231540Z) amd64
} | 
} | (Yes, it needs to be updated, but that's beside the point.)  Granted,
} | this did point out an additional problem, which is:  why was it
} | using the system headers and not the headers from the source tree
} | (a full cvs update was done immediately before the build)?
} 
} Is that the tools build or the regular build? The tools build is supposed
} to work as consistently as possible across platforms. At least the ioctls
} are not NetBSD only (FreeBSD has them too).

 Tools build.  Full command line is:

./build.sh -j 10 -R /usr/local/NetBSD-current/amd64-releasedir -D 
/usr/local/NetBSD-current/amd64-destdir -T 
/usr/local/NetBSD-current/amd64-tooldir -O 
/usr/local/NetBSD-current/amd64-objdir -X /usr/local/NetBSD-current/xsrc -x -u 
-m amd64 tools sourcesets release iso-image-source |& tee ../buildlog

} |  BTW, if you're going to take out getdisksize(), then there is
} | really no point in having #ifdef DIOCGSECTORSIZE, since it won't
} | work even if it does compile.
} 
} It does work with parameters from the command line, as it always did.

 True, but extremely sucky.

}-- End of excerpt from Christos Zoulas


Re: CVS commit: src/sbin/gpt

2015-11-29 Thread Christos Zoulas
On Nov 29,  5:28pm, jnem...@cue.bc.ca (John Nemeth) wrote:
-- Subject: Re: CVS commit: src/sbin/gpt

|  Tools build.  Full command line is:
| 
| ./build.sh -j 10 -R /usr/local/NetBSD-current/amd64-releasedir -D 
/usr/local/NetBSD-current/amd64-destdir -T 
/usr/local/NetBSD-current/amd64-tooldir -O 
/usr/local/NetBSD-current/amd64-objdir -X /usr/local/NetBSD-current/xsrc -x -u 
-m amd64 tools sourcesets release iso-image-source |& tee ../buildlog

Tools build never used the drvctl or the partutil code; read the Makefile.
(How could it? It would have been broken on anything but NetBSD?)

| } It does work with parameters from the command line, as it always did.
| 
|  True, but extremely sucky.

It is no different than before. The tools version never worked on OS's that
lack the ioctls without parameters from the command line.

christos


Re: CVS commit: src/sbin/gpt

2015-11-29 Thread John Nemeth
On Nov 29, 10:32am, "Christos Zoulas" wrote:
}
} This is a multi-part message in MIME format.
} 
} --_--=_1448811166297500
} Content-Disposition: inline
} Content-Transfer-Encoding: 8bit
} Content-Type: text/plain; charset="US-ASCII"
} 
} Module Name:  src
} Committed By: christos
} Date: Sun Nov 29 15:32:46 UTC 2015
} 
} Modified Files:
}   src/sbin/gpt: Makefile gpt.h
} Removed Files:
}   src/sbin/gpt: drvctl.c
} 
} Log Message:
} Remove getdisksize support; we either have the ioctls (current/-7) or we
} don't (non-netbsd-current/7+tools).

 Now, you're just making it harder to pullup improvements to
older releases.

} To generate a diff of this commit:
} cvs rdiff -u -r1.14 -r1.15 src/sbin/gpt/Makefile
} cvs rdiff -u -r1.1 -r0 src/sbin/gpt/drvctl.c
} cvs rdiff -u -r1.20 -r1.21 src/sbin/gpt/gpt.h
} 
} Please note that diffs are not public domain; they are subject to the
} copyright notices on the relevant files.
} 
} 
} --_--=_1448811166297500
} Content-Disposition: inline
} Content-Length: 1289
} Content-Transfer-Encoding: binary
} Content-Type: text/x-diff; charset=us-ascii
} 
} Modified files:
} 
} Index: src/sbin/gpt/Makefile
} diff -u src/sbin/gpt/Makefile:1.14 src/sbin/gpt/Makefile:1.15
} --- src/sbin/gpt/Makefile:1.14Mon Nov  2 21:19:24 2015
} +++ src/sbin/gpt/Makefile Sun Nov 29 10:32:46 2015
} @@ -1,4 +1,4 @@
} -# $NetBSD: Makefile,v 1.14 2015/11/03 02:19:24 jnemeth Exp $
} +# $NetBSD: Makefile,v 1.15 2015/11/29 15:32:46 christos Exp $
}  # $FreeBSD: src/sbin/gpt/Makefile,v 1.7 2005/09/01 02:49:20 marcel Exp $
}  
}  PROG=gpt
} @@ -11,16 +11,6 @@ MAN=   gpt.8
}  SRCS+= backup.c restore.c
}  LDADD+=  -lprop -lutil
}  DPADD+= ${LIBPROP} ${LIBUTIL}
} -
} -.if ${USE_DRVCTL:Uno} == "yes"
} -CPPFLAGS+=-DUSE_DRVCTL
} -SRCS+=drvctl.c
} -.else
} -.PATH: ${.CURDIR}/../fsck
} -CPPFLAGS+=-I${.CURDIR}/../fsck
} -SRCS+=partutil.c
} -.endif
}  .endif
}  
} -
}  .include 
} 
} Index: src/sbin/gpt/gpt.h
} diff -u src/sbin/gpt/gpt.h:1.20 src/sbin/gpt/gpt.h:1.21
} --- src/sbin/gpt/gpt.h:1.20   Sat Nov 28 19:14:46 2015
} +++ src/sbin/gpt/gpt.hSun Nov 29 10:32:46 2015
} @@ -96,16 +96,4 @@ intcmd_show(int, char *[]);
}  int  cmd_type(int, char *[]);
}  int  cmd_unset(int, char *[]);
}  
} -#ifndef HAVE_NBTOOL_CONFIG_H
} -# ifdef USE_DRVCTL
} -int  getdisksize(const char *, u_int *, off_t *);
} -# else
} -#  include "partutil.h"
} -# endif
} -#else
} -# define getdisksize(a, b, c) 0
} -#endif
} -
} -#define GPT_FORCE 1
} -
}  #endif /* _GPT_H_ */
} 
} 
} --_--=_1448811166297500--
} 
}-- End of excerpt from "Christos Zoulas"




Re: CVS commit: src/sbin/gpt

2015-11-29 Thread John Nemeth
On Nov 29,  4:16pm, Christos Zoulas wrote:
} In article <201511291418.tateiwrt002...@server.cornerstoneservice.ca>,
} John Nemeth   wrote:
} >
} > Why did you leave out the call to getdisksize() for when the
} >ioctls don't exist?  Actually, why did you even bother with this
} >patch, since it is pretty much equivalent to what was there before,
} >minus the missing functionality?
} 
} Because who has this functionality (drvctl) and does not have the
} ioctls? Only the NetBSD-6 tools build. This is too much complexity
} for very little benefit. It is simpler to add the ioctls to NetBSD-6
} than keeping all this messy libprop code around (which we have again
} in fsck...) :-)

 The reason I noticed it was due to a build failure.  The system
I was building it on is:

NetBSD msgate 7.0_BETA NetBSD 7.0_BETA (GENERIC.201408231540Z) amd64

(Yes, it needs to be updated, but that's beside the point.)  Granted,
this did point out an additional problem, which is:  why was it
using the system headers and not the headers from the source tree
(a full cvs update was done immediately before the build)?

 BTW, if you're going to take out getdisksize(), then there is
really no point in having #ifdef DIOCGSECTORSIZE, since it won't
work even if it does compile.

}-- End of excerpt from Christos Zoulas


Re: CVS commit: src/sbin/gpt

2015-11-29 Thread Christos Zoulas
On Nov 29,  5:01pm, jnem...@cue.bc.ca (John Nemeth) wrote:
-- Subject: Re: CVS commit: src/sbin/gpt

|  The reason I noticed it was due to a build failure.  The system
| I was building it on is:
| 
| NetBSD msgate 7.0_BETA NetBSD 7.0_BETA (GENERIC.201408231540Z) amd64
| 
| (Yes, it needs to be updated, but that's beside the point.)  Granted,
| this did point out an additional problem, which is:  why was it
| using the system headers and not the headers from the source tree
| (a full cvs update was done immediately before the build)?

Is that the tools build or the regular build? The tools build is supposed
to work as consistently as possible across platforms. At least the ioctls
are not NetBSD only (FreeBSD has them too).

|  BTW, if you're going to take out getdisksize(), then there is
| really no point in having #ifdef DIOCGSECTORSIZE, since it won't
| work even if it does compile.

It does work with parameters from the command line, as it always did.

christos


Re: CVS commit: src/sbin/gpt

2015-11-29 Thread John Nemeth
On Nov 29, 10:40pm, Christos Zoulas wrote:
} On Nov 29,  5:28pm, jnem...@cue.bc.ca (John Nemeth) wrote:
} 
} |  Tools build.  Full command line is:
} | 
} | ./build.sh -j 10 -R /usr/local/NetBSD-current/amd64-releasedir -D 
/usr/local/NetBSD-current/amd64-destdir -T 
/usr/local/NetBSD-current/amd64-tooldir -O 
/usr/local/NetBSD-current/amd64-objdir -X /usr/local/NetBSD-current/xsrc -x -u 
-m amd64 tools sourcesets release iso-image-source |& tee ../buildlog
} 
} Tools build never used the drvctl or the partutil code; read the Makefile.
} (How could it? It would have been broken on anything but NetBSD?)

 I have read the Makefile.  I think there is confusion between
the tool version and the crossbuilt version intended to go in the
release being built.  Obviously, the tool version will use the
system headers, and that may be the one that I saw fail (I don't
have the log anymore).

} | } It does work with parameters from the command line, as it always did.
} | 
} |  True, but extremely sucky.
} 
} It is no different than before. The tools version never worked on OS's that
} lack the ioctls without parameters from the command line.

 Maybe so, but one could just lift the source code from -current
and plunk it on an older version of NetBSD and it would just work.
Now, one can not do that.  Having to update the kernel for a
relatively small userland utility is kind of annoying.

}-- End of excerpt from Christos Zoulas


Re: CVS commit: src/sbin/gpt

2014-10-03 Thread S.P.Zeidler
Hi Jörg,

Thus wrote Joerg Sonnenberger (jo...@netbsd.org):

 Module Name:  src
 Committed By: joerg
 Date: Thu Oct  2 19:15:21 UTC 2014
 
 Modified Files:
   src/sbin/gpt: biosboot.c gpt.c
 
 Log Message:
 Fix tools build on !NetBSD.

It would be nice if it still built on NetBSD, too.

/home/spz/cvs/src/tools/gpt/../../sbin/gpt/biosboot.c: In function 'cmd_biosboot
':
/home/spz/cvs/src/tools/gpt/../../sbin/gpt/biosboot.c:274:22: error: storage siz
e of 'dkw' isn't known
  struct dkwedge_info dkw;

regards,
spz


Re: CVS commit: src/sbin/gpt

2013-10-20 Thread David Laight
On Sat, Oct 19, 2013 at 01:19:03AM +, John Nemeth wrote:
 Module Name:  src
 Committed By: jnemeth
 Date: Sat Oct 19 01:19:03 UTC 2013
 
 Modified Files:
   src/sbin/gpt: gpt.8
 
 Log Message:
 type fix: accommodate. - accomodate.

Why? The correct spelling has two 'm's
At least in accommodation, can't imagine accommodate being different.

David

-- 
avid Laight: da...@l8s.co.uk


Re: CVS commit: src/sbin/gpt

2013-10-20 Thread Marc Balmer
Am 20.10.13 20:25, schrieb David Laight:
 On Sat, Oct 19, 2013 at 01:19:03AM +, John Nemeth wrote:
 Module Name: src
 Committed By:jnemeth
 Date:Sat Oct 19 01:19:03 UTC 2013

 Modified Files:
  src/sbin/gpt: gpt.8

 Log Message:
 type fix: accommodate. - accomodate.
 
 Why? The correct spelling has two 'm's
 At least in accommodation, can't imagine accommodate being different.

The verb is 'to accommodate' with two 'm's.




Re: CVS commit: src/sbin/gpt

2013-10-20 Thread John Nemeth
On Oct 20,  7:25pm, David Laight wrote:
} Subject: Re: CVS commit: src/sbin/gpt
} On Sat, Oct 19, 2013 at 01:19:03AM +, John Nemeth wrote:
}  Module Name:src
}  Committed By:   jnemeth
}  Date:   Sat Oct 19 01:19:03 UTC 2013
}  
}  Modified Files:
}  src/sbin/gpt: gpt.8
}  
}  Log Message:
}  type fix: accommodate. - accomodate.
} 
} Why? The correct spelling has two 'm's
} At least in accommodation, can't imagine accommodate being different.

 Yeah, you're right, should have verified instead of just taking
the change from upstream.  Heck, I even typoed the word typo in
the commit message.

}-- End of excerpt from David Laight