Re: [PATCH] mbuf.9 update
On Wed, Jan 02, 2013 at 07:40:19PM -0600, Ryan Ozmun wrote:
> On Wed, 2 Jan 2013, Jason McIntyre wrote:
>
> > On Wed, Jan 02, 2013 at 03:07:14PM -0600, r...@ozmun.us wrote:
> > > --- mbuf.9 17 Nov 2012 10:55:21 - 1.58
> > > +++ mbuf.9 2 Jan 2013 21:04:56 -
> >
> > this diff doesn;t apply cleanly. is your mailer mangling spaces or
> > something?
> >
> > jmc
> >
> >
>
> Yeah, this one should work:
>
yep. fixed now, thanks.
jmc
> --- mbuf.917 Nov 2012 10:55:21 - 1.58
> +++ mbuf.92 Jan 2013 21:04:56 -
> @@ -25,7 +25,7 @@
> .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
> .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> .\"
> -.Dd $Mdocdate: November 17 2012 $
> +.Dd $Mdocdate: January 2 2013 $
> .Dt MBUF 9
> .Os
> .Sh NAME
> @@ -110,31 +110,38 @@
> };
>
> struct pkthdr {
> -struct ifnet *rcvif;
> -SLIST_HEAD(packet_tags, m_tag) tags;
> -int len;
> -u_int16_t csum_flags;
> -u_int16_t ether_vtag;
> + struct ifnet *rcvif;
> + SLIST_HEAD(packet_tags, m_tag) tags;
> + int len;
> + u_int16_t tagsset;
> + u_int16_t pad;
> + u_int16_t csum_flags;
> + u_int16_t ether_vtag;
> + u_int rdomain;
> struct pkthdr_pf pf;
> };
>
> struct pkthdr_pf {
> void *hdr;
> - u_int rtableid;
> + void *statekey;
> u_int32_t qid;
> u_int16_t tag;
> u_int8_t flags;
> u_int8_t routed;
> + u_int8_t prio;
> + u_int8_t pad[3];
> };
>
> -struct m_ext {
> -caddr_t ext_buf;
> -void(*ext_free)(caddr_t, u_int, void *);
> -void*ext_arg;
> -u_int ext_size;
> -int ext_type;
> -struct mbuf *ext_nextref;
> -struct mbuf *ext_prevref;
> +struct mbuf_ext {
> + caddr_t ext_buf;
> + void(*ext_free)(caddr_t, u_int, void *);
> + void*ext_arg;
> + u_int ext_size;
> + int ext_type;
> + struct ifnet* ext_ifp;
> + int ext_backend;
> + struct mbuf *ext_nextref;
> + struct mbuf *ext_prevref;
> };
>
> struct mbuf {
> @@ -143,7 +150,7 @@
> struct {
> struct pkthdr MH_pkthdr;
> union {
> -struct m_ext MH_ext;
> +struct mbuf_ext MH_ext;
> charMH_databuf[MHLEN];
> } MH_dat;
> } MH;
[PATCH] iovec array size in pppoe
Hi,
I am submitting a small patch for pppoe...
The iovec array in send_padi() can contain either 7 or 8 elements.
The following patch declares the array as having size of 8 rather
than 10.
Does this look OK?
- Michael
Index: client.c
===
RCS file: /cvs/src/usr.sbin/pppoe/client.c,v
retrieving revision 1.24
diff -u -r1.24 client.c
--- client.c5 Nov 2011 09:20:36 - 1.24
+++ client.c3 Jan 2013 03:33:00 -
@@ -144,7 +144,7 @@
static int
send_padi(int fd, struct ether_addr *ea, u_int8_t *srv)
{
- struct iovec iov[10];
+ struct iovec iov[8];
struct pppoe_header ph = {
PPPOE_VERTYPE(1, 1),
PPPOE_CODE_PADI, 0, 0
adduser: better locked password
Adding a user with a locked password is a deliberate action.
Set the password to "*" to stop security(8) from
complaining about the new user.
OK?
Index: adduser.perl
===
RCS file: /home/vcs/cvs/openbsd/src/usr.sbin/adduser/adduser.perl,v
retrieving revision 1.58
diff -u -p -r1.58 adduser.perl
--- adduser.perl22 Sep 2011 10:59:23 - 1.58
+++ adduser.perl3 Jan 2013 03:29:54 -
@@ -800,7 +800,7 @@ sub new_users {
if (&new_users_ok) {
$new_users_ok = 1;
- $cryptpwd = "*";# Locked by default
+ $cryptpwd = "*"; # Locked by default
$cryptpwd = encrypt($password, &salt) if ($password ne "");
$log_cl = "" if ($log_cl eq "default");
Re: [PATCH] mbuf.9 update
On Wed, 2 Jan 2013, Jason McIntyre wrote:
> On Wed, Jan 02, 2013 at 03:07:14PM -0600, r...@ozmun.us wrote:
> > --- mbuf.9 17 Nov 2012 10:55:21 - 1.58
> > +++ mbuf.9 2 Jan 2013 21:04:56 -
>
> this diff doesn;t apply cleanly. is your mailer mangling spaces or
> something?
>
> jmc
>
>
Yeah, this one should work:
--- mbuf.9 17 Nov 2012 10:55:21 - 1.58
+++ mbuf.9 2 Jan 2013 21:04:56 -
@@ -25,7 +25,7 @@
.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
.\"
-.Dd $Mdocdate: November 17 2012 $
+.Dd $Mdocdate: January 2 2013 $
.Dt MBUF 9
.Os
.Sh NAME
@@ -110,31 +110,38 @@
};
struct pkthdr {
-struct ifnet *rcvif;
-SLIST_HEAD(packet_tags, m_tag) tags;
-int len;
-u_int16_t csum_flags;
-u_int16_t ether_vtag;
+ struct ifnet *rcvif;
+ SLIST_HEAD(packet_tags, m_tag) tags;
+ int len;
+ u_int16_t tagsset;
+ u_int16_t pad;
+ u_int16_t csum_flags;
+ u_int16_t ether_vtag;
+ u_int rdomain;
struct pkthdr_pf pf;
};
struct pkthdr_pf {
void *hdr;
- u_int rtableid;
+ void *statekey;
u_int32_t qid;
u_int16_t tag;
u_int8_t flags;
u_int8_t routed;
+ u_int8_t prio;
+ u_int8_t pad[3];
};
-struct m_ext {
-caddr_t ext_buf;
-void(*ext_free)(caddr_t, u_int, void *);
-void*ext_arg;
-u_int ext_size;
-int ext_type;
-struct mbuf *ext_nextref;
-struct mbuf *ext_prevref;
+struct mbuf_ext {
+ caddr_t ext_buf;
+ void(*ext_free)(caddr_t, u_int, void *);
+ void*ext_arg;
+ u_int ext_size;
+ int ext_type;
+ struct ifnet* ext_ifp;
+ int ext_backend;
+ struct mbuf *ext_nextref;
+ struct mbuf *ext_prevref;
};
struct mbuf {
@@ -143,7 +150,7 @@
struct {
struct pkthdr MH_pkthdr;
union {
-struct m_ext MH_ext;
+struct mbuf_ext MH_ext;
charMH_databuf[MHLEN];
} MH_dat;
} MH;
Re: localtime_r on sparc64
Your code is completely wrong.
> Not sure if my code is wrong, or if sparc64 has a bug?
>
> The following code produces different results on sparc64 vs i386.
>
> i386 results:
> $ ./code
> seconds: 1357170317
> year: 2013
>
> sparc64 results:
> $ ./code
> seconds: 1357170432
> year: 1969
>
>
> /*
> * code
> */
> #include
> #include
> #include
> #include
>
> int
> main(void)
> {
> struct timeval tp;
> struct tm *tm, tmBuf;
>
> if (gettimeofday(&tp, NULL) == -1)
> perror("gettimeofday");
>
> printf("seconds: %ld\n", tp.tv_sec);
>
> tm = localtime_r((time_t *)&(tp.tv_sec), &tmBuf);
>
> printf("year: %d\n", tm->tm_year + 1900);
> return (0);
> }
Re: localtime_r on sparc64
My code is wrong! Yikes. Doing undefined things!
Ignore :)
On Wed, Jan 02, 2013 at 06:54:20PM -0500, David Hill wrote:
>Hello -
>
>Not sure if my code is wrong, or if sparc64 has a bug?
>
>The following code produces different results on sparc64 vs i386.
>
>i386 results:
>$ ./code
>seconds: 1357170317
>year: 2013
>
>sparc64 results:
>$ ./code
>seconds: 1357170432
>year: 1969
>
>
>/*
> * code
> */
>#include
>#include
>#include
>#include
>
>int
>main(void)
>{
>struct timeval tp;
>struct tm *tm, tmBuf;
>
>if (gettimeofday(&tp, NULL) == -1)
>perror("gettimeofday");
>
>printf("seconds: %ld\n", tp.tv_sec);
>
>tm = localtime_r((time_t *)&(tp.tv_sec), &tmBuf);
>
>printf("year: %d\n", tm->tm_year + 1900);
>return (0);
>}
localtime_r on sparc64
Hello -
Not sure if my code is wrong, or if sparc64 has a bug?
The following code produces different results on sparc64 vs i386.
i386 results:
$ ./code
seconds: 1357170317
year: 2013
sparc64 results:
$ ./code
seconds: 1357170432
year: 1969
/*
* code
*/
#include
#include
#include
#include
int
main(void)
{
struct timeval tp;
struct tm *tm, tmBuf;
if (gettimeofday(&tp, NULL) == -1)
perror("gettimeofday");
printf("seconds: %ld\n", tp.tv_sec);
tm = localtime_r((time_t *)&(tp.tv_sec), &tmBuf);
printf("year: %d\n", tm->tm_year + 1900);
return (0);
}
Re: [PATCH] mbuf.9 update
On Wed, Jan 02, 2013 at 03:07:14PM -0600, r...@ozmun.us wrote: > --- mbuf.9 17 Nov 2012 10:55:21 - 1.58 > +++ mbuf.9 2 Jan 2013 21:04:56 - this diff doesn;t apply cleanly. is your mailer mangling spaces or something? jmc
units(1): add a count to from-unit
a current undocumented feature of units(1) is that you can specify a
numerical count when in non-interactive mode:
$ units "10 GBP" USD
* 16.167
/ 0.061854395
but neither of these methods work:
$ units 10 GBP USD
$ units 10GBP USD
netbsd made the first of those two methods possible about 11 years ago,
in revision 1.10:
http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/units/units.c?rev=1.10&content-type=text/x-cvsweb-markup
it's a much nicer way to do it, so i've merged the change in, with some
help from otto.
diff below. any oks or objections?
jmc
Index: units.1
===
RCS file: /cvs/src/usr.bin/units/units.1,v
retrieving revision 1.24
diff -u -r1.24 units.1
--- units.1 8 Oct 2011 20:41:12 - 1.24
+++ units.1 2 Jan 2013 22:14:46 -
@@ -26,7 +26,7 @@
.Nm units
.Op Fl qv
.Op Fl f Ar filename
-.Op Ar from-unit to-unit
+.Op Oo Ar count Oc Ar from-unit to-unit
.Sh DESCRIPTION
The
.Nm
@@ -84,11 +84,15 @@
about the number of units loaded.
.It Fl v
Prints the version number.
-.It Ar from-unit Ar to-unit
+.It Oo Ar count Oc Ar from-unit to-unit
Allows a single unit conversion to be done directly from the command line.
No prompting will occur.
The units program will print out
only the result of this single conversion.
+A
+.Ar count
+can be given to specify multiples of
+.Ar from-unit .
.El
.Pp
Powers of units can be specified using the
Index: units.c
===
RCS file: /cvs/src/usr.bin/units/units.c,v
retrieving revision 1.17
diff -u -r1.17 units.c
--- units.c 7 Oct 2011 20:07:25 - 1.17
+++ units.c 2 Jan 2013 22:14:46 -
@@ -612,7 +612,7 @@
usage(void)
{
fprintf(stderr,
- "usage: units [-qv] [-f filename] [from-unit to-unit]\n");
+ "usage: units [-qv] [-f filename] [[count] from-unit to-unit]\n");
exit(3);
}
@@ -651,14 +651,26 @@
}
}
- if (optind != argc - 2 && optind != argc)
+ argc -= optind;
+ argv += optind;
+
+ if (argc != 3 && argc != 2 && argc != 0)
usage();
readunits(userfile);
- if (optind == argc - 2) {
- strlcpy(havestr, argv[optind], sizeof(havestr));
- strlcpy(wantstr, argv[optind + 1], sizeof(wantstr));
+ if (argc == 3) {
+ strlcpy(havestr, argv[0], sizeof(havestr));
+ strlcat(havestr, " ", sizeof(havestr));
+ strlcat(havestr, argv[1], sizeof(havestr));
+ argc--;
+ argv++;
+ argv[0] = havestr;
+ }
+
+ if (argc == 2) {
+ strlcpy(havestr, argv[0], sizeof(havestr));
+ strlcpy(wantstr, argv[1], sizeof(wantstr));
initializeunit(&have);
addunit(&have, havestr, 0);
completereduce(&have);
[PATCH] mbuf.9 update
--- mbuf.9 17 Nov 2012 10:55:21 - 1.58
+++ mbuf.9 2 Jan 2013 21:04:56 -
@@ -25,7 +25,7 @@
.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
.\"
-.Dd $Mdocdate: November 17 2012 $
+.Dd $Mdocdate: January 2 2013 $
.Dt MBUF 9
.Os
.Sh NAME
@@ -110,31 +110,38 @@
};
struct pkthdr {
-struct ifnet *rcvif;
-SLIST_HEAD(packet_tags, m_tag) tags;
-int len;
-u_int16_t csum_flags;
-u_int16_t ether_vtag;
+ struct ifnet *rcvif;
+ SLIST_HEAD(packet_tags, m_tag) tags;
+ int len;
+ u_int16_t tagsset;
+ u_int16_t pad;
+ u_int16_t csum_flags;
+ u_int16_t ether_vtag;
+ u_int rdomain;
struct pkthdr_pf pf;
};
struct pkthdr_pf {
void *hdr;
- u_int rtableid;
+ void *statekey;
u_int32_t qid;
u_int16_t tag;
u_int8_t flags;
u_int8_t routed;
+ u_int8_t prio;
+ u_int8_t pad[3];
};
-struct m_ext {
-caddr_t ext_buf;
-void(*ext_free)(caddr_t, u_int, void *);
-void*ext_arg;
-u_int ext_size;
-int ext_type;
-struct mbuf *ext_nextref;
-struct mbuf *ext_prevref;
+struct mbuf_ext {
+ caddr_t ext_buf;
+ void(*ext_free)(caddr_t, u_int, void *);
+ void*ext_arg;
+ u_int ext_size;
+ int ext_type;
+ struct ifnet* ext_ifp;
+ int ext_backend;
+ struct mbuf *ext_nextref;
+ struct mbuf *ext_prevref;
};
struct mbuf {
@@ -143,7 +150,7 @@
struct {
struct pkthdr MH_pkthdr;
union {
-struct m_ext MH_ext;
+struct mbuf_ext MH_ext;
charMH_databuf[MHLEN];
} MH_dat;
} MH;
Re: diff: dhcp-options(5) vs. dhcpd/tables.c
On Sun, Dec 16, 2012 at 07:24:53PM +0100, MERIGHI Marcus wrote: > Hello, > > playing with option-252 I found it already has a name. Found that as > well: http://marc.info/?l=openbsd-misc&m=126573542214773 > > Wrote a little script to find undocumented options, see end of message. > > I moved some existing blocks when I found them to be in the wrong place. > Added a new section: "DHCP Extensions". > Kept ordering as used in the RFCs. > BTW, format "X" is undocumented in src/usr.sbin/dhcpd/tables.c > > took some time and research, please review: > > Index: dhcp-options.5 > === fixed now by krw. jmc
