Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

lib/libedit/history.c broke the build

0 views
Skip to first unread message

Paul Goyette

unread,
Jul 27, 2011, 7:53:27 AM7/27/11
to
# compile libedit/historyn.o
/test-bed/tools/bin/x86_64--netbsd-gcc -O2 -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wno-traditional -Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Wsign-compare -Werror -DWIDECHAR -I. -I/test-bed/src/lib/libedit -I. -I/test-bed/src/lib/libedit --sysroot=/test-bed/dst -c historyn.c -o historyn.o
cc1: warnings being treated as errors
In file included from historyn.c:3:
/test-bed/src/lib/libedit/history.c: In function 'history_save':
/test-bed/src/lib/libedit/history.c:818: warning: assignment discards qualifiers from pointer target type

*** Failed target: historyn.o


-------------------------------------------------------------------------
| Paul Goyette | PGP 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 |
-------------------------------------------------------------------------

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

Christos Zoulas

unread,
Jul 27, 2011, 9:18:36 AM7/27/11
to
On Jul 27, 4:53am, pa...@whooppee.com (Paul Goyette) wrote:
-- Subject: lib/libedit/history.c broke the build

| # compile libedit/historyn.o
| /test-bed/tools/bin/x86_64--netbsd-gcc -O2 -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wno-traditional -Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Wsign-compare -Werror -DWIDECHAR -I. -I/test-bed/src/lib/libedit -I. -I/test-bed/src/lib/libedit --sysroot=/test-bed/dst -c historyn.c -o historyn.o
| cc1: warnings being treated as errors
| In file included from historyn.c:3:
| /test-bed/src/lib/libedit/history.c: In function 'history_save':
| /test-bed/src/lib/libedit/history.c:818: warning: assignment discards qualifiers from pointer target type
|

Fixed, thanks.

christos

Dave Burgess

unread,
Jul 27, 2011, 2:17:37 PM7/27/11
to
Is there a move afoot to import libusb1.0 into -current in the near
future.

I need it for a project on my primary webserver (a weather station).

Alternately, if there's someone with some experience using the native
usbhid driver, I'd love to pick your brain in private e-mail.

Greg Troxel

unread,
Jul 27, 2011, 7:47:17 PM7/27/11
to

Dave Burgess <bur...@cynjut.net> writes:

> Is there a move afoot to import libusb1.0 into -current in the near
> future.

I have the impression people think that it should be available in
pkgsrc, but apparently making it run on NetBSD isn't so straightforward.

Do you really mean imported into the base system, or just
pkgsrc/devel/libusb1?

Martin Husemann

unread,
Jul 28, 2011, 3:33:01 AM7/28/11
to
On Wed, Jul 27, 2011 at 07:47:17PM -0400, Greg Troxel wrote:
> I have the impression people think that it should be available in
> pkgsrc, but apparently making it run on NetBSD isn't so straightforward.

IIUC it needs kernel changes, but noone detailed them (or filed PRs) yet.

Martin

Gary Duzan

unread,
Jul 28, 2011, 6:59:54 AM7/28/11
to
In Message <Pine.NEB.4.64.1...@ugly.internal.precedence.co.uk>,
Stephen Borrill <net...@precedence.co.uk>wrote:

=>On Thu, 28 Jul 2011, Martin Husemann wrote:
=>>> I think one change is the ability to detach a driver and to reattach ugen.
=>>> So, for instance, detach uaudio and attach ugen. This sort of thing is
=>>> pre-requisite for USB over IP products which I'd love NetBSD to support.
=>>
=>> Is another option to have the ugen ioctls work on uaudio (or everything usb
=>> actually) instead? Detach is easy, but re-attaching ugen is not quite.
=>
=>Fallthrough ioctls? Possibly, but most software seems to be hardwired to
=>enumerate ugen device nodes when looking for something to attach to.

So maybe something like a umux (roughly analogous to wsmux), to
which both a ugen and a more specific driver attach? Though presumably
you would want to lock out use of the alternative devices if another
one is in use, which could complicate things.

Gary Duzan

Wolfgang Solfrank

unread,
Jul 28, 2011, 7:42:32 AM7/28/11
to
Hi,

>>> I think one change is the ability to detach a driver and to reattach ugen.

>>> So, for instance, detach uaudio and attach ugen. This sort of thing is

>>> pre-requisite for USB over IP products which I'd love NetBSD to support.
>>

>> Is another option to have the ugen ioctls work on uaudio (or everything usb

>> actually) instead? Detach is easy, but re-attaching ugen is not quite.

This approach would allow for support of only one (admittedly very common)
usage case, namely libusb.

I can easily envision cases where you'd want to have the possibility to
attach different drivers to one device depending on its usage.

E.g., the openmoko debug board has some ft2232 chip on it, which is supported
by the uftdi driver which then exports the (in this case) two ports of the
chip as serial devices via the ucom driver. However, one of the ports is
wired for JTAG, so the uftdi driver is useless for this. Making things worse,
the uftdi driver currently attaches to the whole device at once instead of
to just one interface at a time. I've got a fix for the latter, but didn't
come around (yet?) to actually write a driver for the jtag part.

All in all, I'd much rather prefer for the usb subsystem to support
detaching a driver and reattaching the device with some other driver
under command control (which could be ugen in order to support libusb).

Ciao,
Wolfgang
--
Wolf...@Solfrank.net Wolfgang Solfrank

Stephen Borrill

unread,
Jul 28, 2011, 5:27:04 AM7/28/11
to
On Thu, 28 Jul 2011, Martin Husemann wrote:
> On Wed, Jul 27, 2011 at 07:47:17PM -0400, Greg Troxel wrote:
>> I have the impression people think that it should be available in
>> pkgsrc, but apparently making it run on NetBSD isn't so straightforward.
>
> IIUC it needs kernel changes, but noone detailed them (or filed PRs) yet.

I think one change is the ability to detach a driver and to reattach ugen.

So, for instance, detach uaudio and attach ugen. This sort of thing is
pre-requisite for USB over IP products which I'd love NetBSD to support.

--
Stephen

Martin Husemann

unread,
Jul 28, 2011, 6:41:33 AM7/28/11
to
On Thu, Jul 28, 2011 at 10:27:04AM +0100, Stephen Borrill wrote:
> I think one change is the ability to detach a driver and to reattach ugen.
> So, for instance, detach uaudio and attach ugen. This sort of thing is
> pre-requisite for USB over IP products which I'd love NetBSD to support.

Is another option to have the ugen ioctls work on uaudio (or everything usb


actually) instead? Detach is easy, but re-attaching ugen is not quite.

Can somebody give a mostly complete list of such issues?

David Young

unread,
Jul 28, 2011, 11:26:35 AM7/28/11
to
On Thu, Jul 28, 2011 at 12:41:33PM +0200, Martin Husemann wrote:
> On Thu, Jul 28, 2011 at 10:27:04AM +0100, Stephen Borrill wrote:
> > I think one change is the ability to detach a driver and to reattach ugen.
> > So, for instance, detach uaudio and attach ugen. This sort of thing is
> > pre-requisite for USB over IP products which I'd love NetBSD to support.
>
> Is another option to have the ugen ioctls work on uaudio (or everything usb
> actually) instead? Detach is easy, but re-attaching ugen is not quite.

I recommend that instead of doing something USB-specific, we create a
drvctl API through which we can modify the kernel's autoconfiguration
data. In effect, the API would modify config(5) lines at run-time:

uaudio0 at uhub1 port 2 configuration 1 interface 0
ugen1 at uhub1 port 2 configuration 1 interface 0

We could immediately re-use such a feature in the kernel, and I think
that we will use it a lot in the future.

Dave

--
David Young OJC Technologies
dyo...@ojctech.com Urbana, IL * (217) 344-0444 x24

0 new messages