headers
Tonnerre LOMBARD | 2 May 2009 04:25
Picon

Binary patch generation script (initial version)

Salut,

Find appended the configure'd version of a preliminary script to
faciliate patch generation following the methods defined earlier
in conversations. It's probably ugly, but it's one more quick
thing, and hey, it works!

The system variables are mostly determined by the running system,
which may not always be right - but some build.sh-like flags can
be passed to overcome this. The OpenSSL key has a default in
/etc/openssl/private/$OS.pem - e.g. NetBSD.pem - and also doesn't
need to be passed. The plist file is generated using diff if
not given; for that to work, the builddir must be kept in the
same location for both builds.

The pullup ID is required to retrieve the message. I'm not sure
there's a better way.

An example would be:

mkpatch /usr/oobj/destdir /usr/obj/destdir 423

It is certainly still going to undergo a lot of work, and your
input is really valued.

Now toast. ;-)

				Tonnerre

(Continue reading)






Permalink
| Reply
| 6 comments  
| 



  

  

  





headers


Alistair Crooks
 | 
2 May 2009 05:18





Re: Binary patch generation script (initial version)


On Sat, May 02, 2009 at 04:25:52AM +0200, Tonnerre LOMBARD wrote:
> Salut,
> 
> Find appended the configure'd version of a preliminary script to
> faciliate patch generation following the methods defined earlier
> in conversations. It's probably ugly, but it's one more quick
> thing, and hey, it works!
> 
> The system variables are mostly determined by the running system,
> which may not always be right - but some build.sh-like flags can
> be passed to overcome this. The OpenSSL key has a default in
> /etc/openssl/private/$OS.pem - e.g. NetBSD.pem - and also doesn't
> need to be passed. The plist file is generated using diff if
> not given; for that to work, the builddir must be kept in the
> same location for both builds.
> 
> The pullup ID is required to retrieve the message. I'm not sure
> there's a better way.
> 
> An example would be:
> 
> mkpatch /usr/oobj/destdir /usr/obj/destdir 423
> 
> It is certainly still going to undergo a lot of work, and your
> input is really valued.
> 
> Now toast. ;-)
> 
> 				Tonnerre


(Continue reading)






Permalink
| Reply
| 5 comments  
| 



  

  

  





headers


Tonnerre LOMBARD
 | 
2 May 2009 14:25






Picon





Re: Binary patch generation script (initial version)


Salut,

On Sat, May 02, 2009 at 04:18:35AM +0100, Alistair Crooks wrote:
> The NetBSD Foundation encourages use of the 2 clause license. This
> would be better:

I'm going to change that in all locations in the end; right now it's
3-claused, yes. Please note that this script is part of the project
I introduced earlier, it lives in the directory "provider". Thus I
chose to be consistent for now.

> Are you using GNU awk specific constructs? If so, please change them
> to one true awk ones.
> 
> For pkgsrc-based utilities, you need to make these much more general.

As I wrote, this script is already configure'd on a NetBSD host. It was
just made available to everyone in a useful shape before I update the
package in pkgsrc.

The AWK=gawk has indeed been set by configures AC_PROG_AWK macro.

> As already indicated, please consider the use of netpgp and the
> existing web of trust. There's a package in pkgsrc/security/netpgp.

That would mean changing the current patch format entirely and
rewriting the other tools; I'd prefer to get them running first
and to introduce a new patch format with PGP later if required.
For now, OpenSSL was chosen in order to add as few out-of-base
dependencies as possible.

(Continue reading)






Permalink
| Reply
| 4 comments  
| 



  

  

  





headers


Thor Lancelot Simon
 | 
3 May 2009 03:13





Re: Binary patch generation script (initial version)


On Sat, May 02, 2009 at 02:25:27PM +0200, Tonnerre LOMBARD wrote:
[Alistair wrote]:> 
> > As already indicated, please consider the use of netpgp and the
> > existing web of trust. There's a package in pkgsrc/security/netpgp.
> 
> That would mean changing the current patch format entirely and
> rewriting the other tools; I'd prefer to get them running first
> and to introduce a new patch format with PGP later if required.
> For now, OpenSSL was chosen in order to add as few out-of-base
> dependencies as possible.

Please don't change this to use PGP by default.  If the intent is to
have the NetBSD Foundation produce patches in a centralized way and
distribute them to users, a hierarchical trust model is better -- and
we already have the tools and libraries in the system to support it
the way you wrote your code.

--

-- 
Thor Lancelot Simon	                                   tls <at> rek.tjls.com
    "Even experienced UNIX users occasionally enter rm *.* at the UNIX
     prompt only to realize too late that they have removed the wrong
     segment of the directory structure." - Microsoft WSS whitepaper







Permalink
| Reply
| 1 comment  
| 



  

  

  





headers


Alistair Crooks
 | 
3 May 2009 03:19





Re: Binary patch generation script (initial version)


On Sat, May 02, 2009 at 02:25:27PM +0200, Tonnerre LOMBARD wrote:
> Salut,
> 
> On Sat, May 02, 2009 at 04:18:35AM +0100, Alistair Crooks wrote:
> > The NetBSD Foundation encourages use of the 2 clause license. This
> > would be better:
> 
> I'm going to change that in all locations in the end; right now it's
> 3-claused, yes. Please note that this script is part of the project
> I introduced earlier, it lives in the directory "provider". Thus I
> chose to be consistent for now.
> 
> > Are you using GNU awk specific constructs? If so, please change them
> > to one true awk ones.
> > 
> > For pkgsrc-based utilities, you need to make these much more general.
> 
> As I wrote, this script is already configure'd on a NetBSD host. It was
> just made available to everyone in a useful shape before I update the
> package in pkgsrc.
> 
> The AWK=gawk has indeed been set by configures AC_PROG_AWK macro.
> 
> > As already indicated, please consider the use of netpgp and the
> > existing web of trust. There's a package in pkgsrc/security/netpgp.
> 
> That would mean changing the current patch format entirely and
> rewriting the other tools; I'd prefer to get them running first
> and to introduce a new patch format with PGP later if required.
> For now, OpenSSL was chosen in order to add as few out-of-base

(Continue reading)






Permalink
| Reply
| 1 comment  
| 



  

  

  





headers


Mindaugas Rasiukevicius
 | 
4 May 2009 04:08






Picon





Fw: Thread scheduling and related interfaces in NetBSD 5.0


Begin forwarded message:

Date: Sun, 3 May 2009 21:45:56 +0100
From: Mindaugas Rasiukevicius <rmind <at> netbsd.org>
To: netbsd-announce <at> netbsd.org
Subject: Thread scheduling and related interfaces in NetBSD 5.0

Dear All,

A lot of new features were implemented in the NetBSD 5.0 release, and many
improvements were made in the areas of scheduling and threading.  Please
find the PDF document which shortly reviews new scheduling interfaces.

        "Thread scheduling and related interfaces in NetBSD 5.0"

        http://www.netbsd.org/~rmind/pub/netbsd_5_scheduling_apis.pdf

Thank you.

--

-- 
Mindaugas







Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Paul Goyette
 | 
4 May 2009 13:45





Extension to snprintb(3)


Folks,

Having recently purchased a couple of new processors, and trying to make 
the output from cpuctl(8) look reasonable when decoding the various CPU 
features, it's become apparent that the current snprintb(3) is somewhat 
awkward to use.  For large bit masks, one either has to manually "split" 
the desired value across multiple calls (which leads to drastiscally 
uneven line lengths and/or an unnecessarily large number of short lines) 
or suffer from excessively long lines.

I propose a modified version of snprintb(3) which fills its output 
buffer only with complete bit/field values.  In addition to the current 
return value, this modified version would take an additional u_quad_t 
argument which would be set to the bit(s) that were NOT decoded in the 
current output.  This would allow one to repeatedly call the new 
function, with a fixed-sized buffer, until all bits were decoded, and 
would result in output lines that were reasonably equal in length.

Is this a reasonable idea?  Any suggestion on what this new function 
should be called?

int snprintbx(char *buf, size_t buflen, const char *fmt, u_quad_t *val);

-------------------------------------------------------------------------
|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:      |
| Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul at whooppee.com   |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------


(Continue reading)






Permalink
| Reply
| 7 comments  
| 



  

  

  





headers


Christos Zoulas
 | 
4 May 2009 17:03





Re: Extension to snprintb(3)


In article <Pine.NEB.4.64.0905040425310.2990 <at> quicky.whooppee.com>,
Paul Goyette  <paul <at> whooppee.com> wrote:
>Folks,
>
>Having recently purchased a couple of new processors, and trying to make 
>the output from cpuctl(8) look reasonable when decoding the various CPU 
>features, it's become apparent that the current snprintb(3) is somewhat 
>awkward to use.  For large bit masks, one either has to manually "split" 
>the desired value across multiple calls (which leads to drastiscally 
>uneven line lengths and/or an unnecessarily large number of short lines) 
>or suffer from excessively long lines.
>
>I propose a modified version of snprintb(3) which fills its output 
>buffer only with complete bit/field values.  In addition to the current 
>return value, this modified version would take an additional u_quad_t 
>argument which would be set to the bit(s) that were NOT decoded in the 
>current output.  This would allow one to repeatedly call the new 
>function, with a fixed-sized buffer, until all bits were decoded, and 
>would result in output lines that were reasonably equal in length.
>
>Is this a reasonable idea?  Any suggestion on what this new function 
>should be called?
>
>int snprintbx(char *buf, size_t buflen, const char *fmt, u_quad_t *val);

Sounds ok to me.

christos



(Continue reading)






Permalink
| Reply
| 4 comments  
| 



  

  

  





headers


Jan Schaumann
 | 
4 May 2009 17:39






Favicon

Gravatar





"test -e" tests target of symlink


Hi,

test(1) says:

     -e file       True if file exists (regardless of type).

Consider:

$ ls -l /tmp/foo /tmp/bar
ls: /tmp/foo: No such file or directory
lrwx------  1 jschauma  wheel  8 May  4 11:35 /tmp/bar -> /tmp/foo
$ 

I would have expected "test -e /tmp/bar" to evaluate to true.  Instead,
it follows the symlink and evaluates to false:

$ test -e /tmp/bar
$ echo $?
1

IOW, it uses stat(2) instead of lstat(2):

        if (mode == FILSYM ? lstat(nm, &s) : stat(nm, &s))

(mode == FILSYM only if "-L" or "-h" was given)

Is this intentional, and if so, should this maybe be explicitly noted in
the manual page?

-Jan

(Continue reading)






Permalink
| Reply
| 1 comment  
| 



  

  

  





headers


Arnaud Lacombe
 | 
4 May 2009 19:27






Picon

Gravatar





Re: Extension to snprintb(3)


Hi all,

On Mon, May 4, 2009 at 7:45 AM, Paul Goyette <paul <at> whooppee.com> wrote:
> int snprintbx(char *buf, size_t buflen, const char *fmt, u_quad_t *val);
>
wouldn't the C99 `uint64_t' variant be more desirable than `u_quad_t' ?

 - Arnaud







Permalink
| Reply
| 1 comment  
| 



  

  

  

  


  





    



Gmane