wtf patch

I'm pretty sure this is the right list for this...
I was using RSVP and realized it didn't have RSVP in there.  I added a 
patch for it.

Jim

--- acronyms	2005-11-04 15:45:32.000000000 -0500
+++ acronyms	2006-02-28 20:03:38.000000000 -0500
 <at>  <at>  -179,6 +179,7  <at>  <at> 
 ROTFL	rolling on the floor laughing
 RP	responsible person
 RSN	real soon now
+RSVP	repondez s'il vous plait (please reply)
 RTFB	read the fine/fucking book
 RTFC	read the fine/fucking code
 RTFD	read the fine/fucking documentation

EFI GPT and wedges/disklables on amd64 i386 and ia64

Hi,

 As there are now shipping EFI-based i386 machines, we should consider
how the partitioning will work on all the EFI machines.  Since EFI itself
may often need to read (and write) into at least one partition, a simple
disklabel-only scheme won't work.  Are wedges over the GPT[1] partitions
the way to go?  Or do we do a i386-like GPT+disklabel thing?  I believe
FreeBSD/ia64 is using a GPT-only scheme.

For starters the GPT partitioning program from FreeBSD should be ported
and imported.  It uses some FreeBSD-specific ioctls for determining
size of the disk, and I couldn't find an equivalent in NetBSD.  I'd be
willing to try to get it ported if I got some pointers in this area.

Also, for the GPT+disklabel possibility a gptlabel(8) program similar to
mbrlabel(8) may need to be written.  Or is a wedges-based system with only
the GPT on disk the way of the future?

	Jonathan Kollasch

[1] http://en.wikipedia.org/wiki/GUID_Partition_Table

Re: EFI GPT and wedges/disklables on amd64 i386 and ia64

On Feb 28, 2006, at 9:54 PM, Jonathan A. Kollasch wrote:

>  As there are now shipping EFI-based i386 machines, we should consider
> how the partitioning will work on all the EFI machines.  Since EFI  
> itself
> may often need to read (and write) into at least one partition, a  
> simple
> disklabel-only scheme won't work.  Are wedges over the GPT[1]  
> partitions
> the way to go?  Or do we do a i386-like GPT+disklabel thing?  I  
> believe
> FreeBSD/ia64 is using a GPT-only scheme.

Wedges will be the solution for GPT.  There are still some wedge  
issues to work out yet.  I have plans to work on this some more in  
the near future.

> For starters the GPT partitioning program from FreeBSD should be  
> ported
> and imported.  It uses some FreeBSD-specific ioctls for determining
> size of the disk, and I couldn't find an equivalent in NetBSD.  I'd be
> willing to try to get it ported if I got some pointers in this area.

I'm not so sure the GPT program from FreeBSD should be imported as-is.

> Also, for the GPT+disklabel possibility a gptlabel(8) program  
> similar to
> mbrlabel(8) may need to be written.  Or is a wedges-based system  
> with only

netBSD dev/ugen / libusb

Hi All,

I have found an issue with netBSD dev/ugen - libusb and am after a bit of
direction/advice.

This has come about whilst trying to get nut (ups monitoring) software
operational under netBSD. Nut uses libusb as the layer to access usb
devices, the device I am using being a MGE Nova 1100 UPS.

Software versions are:

netBSD 3.0_STABLE (amd64)

libusb 0.1.12

nut 2.0.3

Libusb offers a function usb_interrupt_read, the function looks like

int usb_interrupt_read(usb_dev_handle *dev, int ep, char *bytes, int size,
int timeout)

A call to this should I understand return with *char buffer filled with data
from usb device OR timeout after int timeout seconds.

The problem seems to be that the dev/ugen code ugen_do_read does not respect
this timeout and will not return until such time as data is returned from
the usb device.

End result is that when libusb usb_interrupt_read is called it won't return

Re: netBSD dev/ugen / libusb

On Fri, Mar 17, 2006 at 05:38:08PM +1100, Nevil Thatcher wrote:
> With this patch the program works quite happily, but is this a valid
> approach?

Yes, it is a valid aproach - but it sounds also easy to chnage the kernel
to respect the timeout set by the ioctl - maybe you should file a PR?

Martin