headers
Stephen Borrill | 2 May 2003 17:36
Picon
Favicon

Building floppies

I'm trying to build some install floppies with audioctl and audioplay on
them (basing it on ramdisk-big). Unlike the other programs, audioctl and
audioplay aren't found as /usr/src/usr.bin/≤progname>. I put the following
lines in my list file:

PROG   usr/bin/audioctl
PROG   usr/bin/audioplay

SPECIAL audioctl        srcdir usr.bin/audio/ctl
SPECIAL audioplay       srcdir usr.bin/audio/play

However because there is no reference to usr/bin/audio/common, the library
functions from there aren't included and so there are lots of undefined
references when linking.

Is there something I can do to make it all be included automatically or
must I build up the audio library separately?

--

-- 
Stephen
Permalink | Reply | 1 comment |
headers
Luke Mewburn | 3 May 2003 03:51
Picon

Re: Building floppies

On Fri, May 02, 2003 at 04:36:16PM +0100, Stephen Borrill wrote:
  | I'm trying to build some install floppies with audioctl and audioplay on
  | them (basing it on ramdisk-big). Unlike the other programs, audioctl and
  | audioplay aren't found as /usr/src/usr.bin/≤progname>. I put the following
  | lines in my list file:
  | 
  | PROG   usr/bin/audioctl
  | PROG   usr/bin/audioplay
  | 
  | SPECIAL audioctl        srcdir usr.bin/audio/ctl
  | SPECIAL audioplay       srcdir usr.bin/audio/play
  | 
  | However because there is no reference to usr/bin/audio/common, the library
  | functions from there aren't included and so there are lots of undefined
  | references when linking.
  | 
  | Is there something I can do to make it all be included automatically or
  | must I build up the audio library separately?

For now you'll need to work around this similar to how
distrib/utils/x_dhclient does it...
Permalink | Reply | 0 comments |
headers
John Gordon | 8 May 2003 02:10
Picon
Favicon

Cygwin Build Patch

Hello all,

I have completed a set of changes to the NetBSD build infrastructure that allow
me to build at least two architectures (i386 and my ibmnws platform, a PowerPC
box) under Cygwin/Windows XP.

I have made a patch for this, and provide instructions on the required
configuration of Cygwin (including a small change needed to the Cygwin CVS
implementation to avoid case-insensitivity filename clash problems) on my web
site at:

    http://www.bluedonkey.org/cgi-bin/twiki/bin/view/Netbsd/CygwinBuild

I will also file a change request problem report, with the patch pasted into
it, so that this information is recorded somewhere.

The speed of the build, at least on my XP box, is not great, but it does work.
I have managed to build everything all the way through to generating a RAM disk
root file system based kernel for the ibmnws box, and that boots successfully.

Any comments, questions, or problems using these changes please let me know. I
will try my best to help out with any fixes - I've probably seen most of the
errors that are likely to crop up now ;-)

Rgds,
John...

=====
Rate Corporate America at http://exec-ratings.bluedonkey.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
David | 15 May 2003 22:27
Picon

multiple consumers of msmux

	I have a keyboard with a random selection of extra keys, which I'd
	like to map to do something useful with mserv. Its trivial enough
	to do this in a window manager under X, but I'd like something
	that works all the time.

	Is it possible to open the keyboard wsmux without disrupting the
	normal use? (So I could have a small daemon listening to the
	keyboard events and acting on the special keys).

--

-- 
		David Brownlee
Permalink | Reply | 7 comments |
headers
Lennart Augustsson | 15 May 2003 23:23
Favicon
Gravatar

Re: multiple consumers of msmux

No, that's currently not possible.  Well, you could set something up
with two muxes, and your program would pass the unused events from
one to the other, but it would be awkward.

David wrote:

>	I have a keyboard with a random selection of extra keys, which I'd
>	like to map to do something useful with mserv. Its trivial enough
>	to do this in a window manager under X, but I'd like something
>	that works all the time.
>
>	Is it possible to open the keyboard wsmux without disrupting the
>	normal use? (So I could have a small daemon listening to the
>	keyboard events and acting on the special keys).
>
>  
>
Permalink | Reply | 6 comments |
headers
David Brownlee | 16 May 2003 11:03
Picon

Re: multiple consumers of msmux

	Does it seem like something that would be generally useful?
	Maybe by having a separate device similar to wsmuxctl?

On Thu, 15 May 2003, Lennart Augustsson wrote:

> No, that's currently not possible.  Well, you could set something up
> with two muxes, and your program would pass the unused events from
> one to the other, but it would be awkward.
>
> David wrote:
>
> >	I have a keyboard with a random selection of extra keys, which I'd
> >	like to map to do something useful with mserv. Its trivial enough
> >	to do this in a window manager under X, but I'd like something
> >	that works all the time.
> >
> >	Is it possible to open the keyboard wsmux without disrupting the
> >	normal use? (So I could have a small daemon listening to the
> >	keyboard events and acting on the special keys).
> >
> >
> >
>
>
>

--

-- 
		David/absolute          -- www.netbsd.org: No hype required --
(Continue reading)

Permalink | Reply | 5 comments |
headers
Erik E. Fair | 17 May 2003 21:31
Picon

Re: multiple consumers of msmux

I think such a thing would be very useful - there are often 
specialized keys on keyboards that we could then bind to firing up 
various programs (e.g. "www" key fires up your favorite browser, or 
an "internet" key that fires up PPP).

	Erik <fair <at> clock.org>
Permalink | Reply | 4 comments |
headers
David Brownlee | 20 May 2003 19:09
Picon

Re: multiple consumers of msmux

On Sat, 17 May 2003, Erik E. Fair wrote:

> I think such a thing would be very useful - there are often
> specialized keys on keyboards that we could then bind to firing up
> various programs (e.g. "www" key fires up your favorite browser, or
> an "internet" key that fires up PPP).

	<violently agreeing>
	Traditionally this would be done inside the windowmanager
	(or related tool), which is very convenient for the
	webbrowser, less convenient for the ppp link, and bloody
	inconvenient for audio control (when xlock is running or
	on non X virtual console).

	In general anything that fires up or controls X applications
	should be left to the window manager or related tool, which
	would mean any tool that handled the other options would
	not need to be able to run under a 'the current' user, or
	require an X display.
	</violently agreeing>

	Would you want to be able to has a 'wsfilter' or similar
	device which would 'attach' to a wsmux and steal any keys
	in its map?

--

-- 
		David/absolute          -- www.netbsd.org: No hype required --
Permalink | Reply | 0 comments |
headers
Erik E. Fair | 20 May 2003 21:24

Re: multiple consumers of msmux

Dennis Ritchie gave the UNIX world "streams" as the answer to the
question, "why are tty line disciplines so hard to write?" It is
very, very important to distinguish that from its later perversion
into System V's networking API to compete against BSD sockets.

The original paper is still available at:

	http://cm.bell-labs.com/cm/cs/who/dmr/st.html

The key notion is protocol modules that can be pushed on and popped
from a stack, so that I/O from a serial is processed by all of the
stream modules on the stack in turn. In a system like this, it
would in principle be easy to push a keystroke/keycode normalizer
on top of a keyboard serial interface, and then push a module on
top of that to perform some action from a "help" keypress (regardless
of whatever keycode came out from pressing a "help" key on a given
keyboard).

That module could also decide whether to pass on the keypress to
the next module up (ultimately to the userland program), or eat
the keypress after doing whatever processing.

Now, as much as I'd like to see dmr's streams in NetBSD, that is
not what I am suggesting now - that's more work than is necessary
for this, I believe. What I think we need in wscons is an interface
or tap like bpf(4) so that a program could snoop the keypresses
and do things. Your wsfilter notion sounds interesting...

	Erik <fair <at> clock.org>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Greg A. Woods | 20 May 2003 21:53
X-Face
Favicon

Re: multiple consumers of msmux

[ On Tuesday, May 20, 2003 at 12:24:39 (-0700), Erik E. Fair wrote: ]
> Subject: Re: multiple consumers of msmux 
>
> Dennis Ritchie gave the UNIX world "streams" as the answer to the
> question, "why are tty line disciplines so hard to write?" It is
> very, very important to distinguish that from its later perversion
> into System V's networking API to compete against BSD sockets.

It's also very important to note that many serious limitations in the
original Ritchie implementation of streams, some of which were finally
fixed in the UNIX System V Release 4 implementation.  :-)

In particular are the issues in the original implementation which would
need to be overcome to support your deisred application:

   Although the new organization performs well, it has several peculiarities    
   and limitations. Some of them seem inherent, some are fixable, and some      
   are the subject of current work.                                             

[[ .... ]]

   Streams are linear connections; by themselves, they support no notion of     
   multiplexing, fan-in or fan-out.

There is multiplexing support in the later implementations.

There are also serious issues in the original design with flow control,
accounting & scheduling, error handling, and so on.  Some of these
problems are also solved in the later implemenations, but perhaps not all.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane