Re: Performance issue with rfork() and single socketpairs versus multiple socketpairs.

[Peter Wemm]

Brian Somers wrote:
> > "Scott Hess" wrote:
> > 
> > > I've found an odd performance issue that I cannot explain.  I'm using
> > > socketpairs to communicate with multiple rfork(RFPROC) processes.
> > 
> > Use 'pipe(2)' rahter than 'socketpair(2)' as both are bidirectional and
> > pipe is a LOT faster.
> 
> Although pipe(2)'s bi-directional capabilities are not standard (I've 
> been stung by this in the past :-()

Neither is rfork()...

Cheers,
-Peter




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Device Drivers

[Kelly Yancey]

On Mon, 24 Jan 2000, Nathan Cohen wrote:

> I;d like to start contributing to the project, and I've heard unanimously a good 
>place to start is device drivers. However, I'd like to try something other than sound 
>cards (the only major recommendation I've heard so far) 
> 
> Are there any NICs, or other driver areas where FreeBSD could use some help?
> 
> Thanks
> 

  Check http://www.posi.net/freebsd/drivers/hardware-list.phtml for some
hardware people would like to see supported (surely, there is more, but that
is a start).

  Kelly

--
Kelly Yancey  -  [EMAIL PROTECTED]  -  Richmond, VA
Analyst / E-business Development, Bell Industries  http://www.bellind.com/
Maintainer, BSD Driver Database   http://www.posi.net/freebsd/drivers/
Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: indirection in bus space

[Luoqi Chen]

> I think it is difficult to implement such conversion because:
> 
>   - Not only bus space stuff also resource manager stuff need to
> perform such conversion.

Why? Both bus_space_handle_t and bus_space_tag_t are supposed to be
opaque types. Resource manager needs not know the implementation details.

>   - The type of the bus_space_handle_t can by determined only by the
> bus tag.  The isa_alloc_resourcev (new function) cannot modify bus
> tag because what it does is only to allocate resources and it
> cannot register the address to the bus_space_handle_pc98.  But
> allocated resources must be stored into bus_space_handle_pc98.
> 
We could create a new resource type SYS_RES_IOPORT_ARRAY, and intercept
it in all isa_*_resoruce() methods. In isa_alloc_resource(), we malloc and
return a fake resource record, in which we store I386_BUS_PIO_IND as
bus tag and address of bus_space_handle_pc98 as bus handle. And in
isa_release_resource(), we first release the underlying resources stored
in the bus_space_handle_pc98 record and then free the fake resource record
itself. It should be safe as long as we don't manipulate this resource by
direct resource manager calls, which we shouldn't do anyway.
(or we should implement it at the root bus level, if pci devices in
pc98 systems also use discrete port addresses).

-lq


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: indirection in bus space

[KATO Takenori]

Luoqi Chen <[EMAIL PROTECTED]> wrote:

> You could set the handle to point to the structure instead:

I think it is difficult to implement such conversion because:

  - Not only bus space stuff also resource manager stuff need to
perform such conversion.
  - The type of the bus_space_handle_t can by determined only by the
bus tag.  The isa_alloc_resourcev (new function) cannot modify bus
tag because what it does is only to allocate resources and it
cannot register the address to the bus_space_handle_pc98.  But
allocated resources must be stored into bus_space_handle_pc98.

---+--+
KATO Takenori <[EMAIL PROTECTED]>  |FreeBSD   |
Dept. Earth Planet. Sci, Nagoya Univ.  |The power to serve!   |
Nagoya, 464-8602, Japan|  http://www.FreeBSD.org/ |
   |http://www.jp.FreeBSD.org/|
 FreeBSD(98) 3.3R-Rev. 01 available!   +==+


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Learning the FreeBSD Kernel

[Greg Lehey]

On Monday, 24 January 2000 at 10:04:10 +0100, Jeroen Ruigrok/Asmodai wrote:
> -On [2124 08:01], Mike Smith ([EMAIL PROTECTED]) wrote:
>>> I can't agree with Mike Smith that reading the code is adequate.  It
>>> certainly doesn't apply to newcomers, but it doesn't even apply to
>>> seasoned hackers like Mike: the BSD style doesn't provide for adequate
>>> comments, and so what you see from the code is mainly tactics, not
>>> strategy.
>>
>> You miss my point; you don't want to be writing a driver until you know
>> what you're doing.  Documentation on an OS' driver interface won't teach
>> you that; it's something that's really only ever gleaned from experience.
>
> This I agree on with Mike.  Writing device drivers isn't like
> writing an application.

In this respect, it is: I understand Mike to be saying "you can't
learn by reading, you learn by doing".

> The documentation I am writing will definately not be a tutorial
> style piece of documentation, but a reference guide with sufficient
> background material so that people a bit familiar with FreeBSD on
> source level (note the ``a bit'') will get enough ideas and clues
> from it to proceed forwards.

I think it would benefit from tutorial style.  That wouldn't be
enough, but defining the workspace would make people a lot more
comfortable.

> I do not think making it a tutorial will be beneficial in the long run,
> since I would have to discuss kernel sources, gdb, ddb and a number of
> other things on the side.

And that's a bad idea?  I'd disagree.

> I just know, from experience, that writing a driver involves more
> than just code.

Definitely.  And that's one thing you've got to tell the newcomers.

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Learning the FreeBSD Kernel

[Greg Lehey]

On Monday, 24 January 2000 at 17:40:13 +0900, Daniel C. Sobral wrote:
> Documenting the available debugging tools and useful debugging
> techniques would be mostly welcome. Aside from "how do I use the kernel
> debugger", use of tools such as truss, and loading symbol tables to
> kld's (see Greg Lehey's documentation on debugging vinum) would be
> useful tutorials.

Kick me on this in a month or so's time and I'll try to make a
generalized document out of this one.  Cross my palm with silver and
I'll even write a "how to develop a driver" document.

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Learning the FreeBSD Kernel

[Greg Lehey]

On Monday, 24 January 2000 at  7:09:35 -0800, Mike Smith wrote:
>> On Sun, 23 Jan 2000, Mike Smith wrote:
>>
 I can't agree with Mike Smith that reading the code is adequate.  It
 certainly doesn't apply to newcomers, but it doesn't even apply to
 seasoned hackers like Mike: the BSD style doesn't provide for adequate
 comments, and so what you see from the code is mainly tactics, not
 strategy.
>>>
>>> You miss my point; you don't want to be writing a driver until you know
>>> what you're doing.  Documentation on an OS' driver interface won't teach
>>> you that; it's something that's really only ever gleaned from experience.
>>
>> The problem is, you can't even find what the interfaces are.  Reading the
>> code isn't very useful if you can't even find the right place to start
>> from.  At least the interface points could be listed, so that someone
>> would know where to begin.
>
> Listing the interface points won't help unless you know which ones are
> relevant to what you're trying to do.  I say it again; first you need to
> know how to write a device driver, then you need to know what the
> available tools are to get the job done.  Having only the latter does
> not help at all with the former.

I'd like you to see you build a timber roofing structure:

 "Listing the kinds of beam won't help unless you know which ones are
  relevant to what you're trying to do.  I say it again; first you
  need to know how to build a roof, then you need to know what the
  available tools are to get the job done.  Having only the latter
  does not help at all with the former."

I repeat: before you can do a job which requires tools, you need to be
familiar with those tools.  How do you get familiar with those tools?
You work with them.  The first step of familiarity with the tools
doesn't make you an expert, but it helps you know what they look like,
and when you find yourself up in the roof and trying to join two beams
together, you'll at least have an idea which tools might be of use.

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Learning the FreeBSD Kernel

[Greg Lehey]

On Monday, 24 January 2000 at  2:28:23 -0500, Chuck Robey wrote:
> On Mon, 24 Jan 2000, William A. Maniatty wrote:
>
>> Both Chuck Robey and Mike Smith have some points, but that won't
>> stop me from giving my opinion :-).  Mike is correct that experience is
>> key to being a solid systems software developer, who writes device drivers.
>> Now the next question is how can someone get experience?  By developing
>> systems software (which by the way they should only do if they have
>> experience at it :-)).
>>
>> Traditionally there are two approaches:
>>   1) Have a friend available and bug them for help when you get stuck :-)
>>   2) Read the documentation.
>>   3) Read the code and lose a whole lot of productivity without certainty
>>  of figuring it out on your own.
>>   4) Dismiss the whole problem as unmanageable and throw your
>>  weight behind a more productive project.
>
> I know where Mike's coming from.  Wait until the next guy posts on the
> list "I don't really know how to program, but please tell what 'C' is, and
> how to write a device driver".  We had a pretty nasty flamewar over that
> maybe (I think) 9 months ago, and it still hurts folks, to be accused of
> conceit, when the guy was asking a grossly unanswerable question, and
> wouldn't believe it couldn't be boiled down to a 4 paragraph "device
> drivers for dummies" thing.  Mike wants to avoid dealing with a horde of
> folks like that.

I don't think anybody's picking on Mike, but there are some obvious
points here:

1.  This isn't an idiot asking inappropriate questions, it's a college
professor asking very appropriate questions.
2.  Nobody's asking Mike to do anything.

I think that one of the problems Mike is showing (and it's not just
Mike, but somehow it seems to be his turn to be picked on right now
:-) is that it's painful enough to go through the learning experience
the first time, and you don't really want to go back and try again and
again.  Unfortunately, this doesn't make it any less necessary.  I was
hoping that Bill's student might help create better documentation as
well; if he succeeds in that, generations of FreeBSD driver
programmers will burn incense at his shrine.

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Learning the FreeBSD Kernel

[Greg Lehey]

On Monday, 24 January 2000 at  2:44:43 -0500, William A. Maniatty wrote:
> Hi There:
>
> Chuck Robey Writes:
>> I know where Mike's coming from.  Wait until the next guy posts on the
>> list "I don't really know how to program, but please tell what 'C' is, and
>> how to write a device driver".  We had a pretty nasty flamewar over that
>> maybe (I think) 9 months ago, and it still hurts folks, to be accused of
>> conceit, when the guy was asking a grossly unanswerable question, and
>> wouldn't believe it couldn't be boiled down to a 4 paragraph "device
>> drivers for dummies" thing.  Mike wants to avoid dealing with a horde of
>> folks like that.
>>
>> I can't really blame Mike, it's impossible to make people understand that
>> you can't boil everything down to a 30 second sound bite.  BUT I still
>> wish there was a map to interfaces.
>
> Ah!  I wasn't aware of this.  I would be somewhat thin skinned too,
> too many requests for a free lunch can be a problem.  On the other hand
> I still think: (i) I'd still like my student to take a crack at it,
> since he would pick up some understanding of kernel programming by doing it
> (a good thing!) (ii) the project might help motivated (and good) people
> pick up FreeBSD kernel programming and (iii) people can be pointed to
> the manual and told to return if they have a specific question.

These were pretty much exactly the reasons I thought of.  I was
thinking (iii) might be getting your guy to do the documentation :-)

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Learning the FreeBSD Kernel

[Greg Lehey]

On Sunday, 23 January 2000 at 22:35:53 -0800, Mike Smith wrote:
>> I can't agree with Mike Smith that reading the code is adequate.  It
>> certainly doesn't apply to newcomers, but it doesn't even apply to
>> seasoned hackers like Mike: the BSD style doesn't provide for adequate
>> comments, and so what you see from the code is mainly tactics, not
>> strategy.
>
> You miss my point; you don't want to be writing a driver until you know
> what you're doing.  Documentation on an OS' driver interface won't teach
> you that; it's something that's really only ever gleaned from experience.

Hmm.  I don't really see what your reply has to do with what you
quote.  I also strongly suspect that *nobody* really knows what he's
doing when he writes his first driver, and that it's an interative
process to learn how to get there.  Most of us were ``thrown in the
deep end'', and somehow we learnt to swim.  But in detail, what we all
did was to look at all documentation we could find, including of
course the source code.  I didn't say that reading the source code is
bad; it's definitely part of it, just not enough.

To be fair, this is an experience I've made with multiple operating
systems now.  FreeBSD is no worse than the others; writing drivers is
inadequately described in every system I know.

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: indirection in bus space

[Luoqi Chen]

> > Why have two files bus_at386.h and bus_pc98.h? I386_BUS_PIO_IND should be
> > able to live with I386_BUS_PIO and I386_BUS_MEMIO happily together.
> 
> Because they are different in the type of bus_space_tag_t from each
> other.  It is the u_long in PC/AT and the structure in PC-98.  For
> example, bus_space_read_1()s of them are:
> 
>   PC/AT:
>   bus_space_read_1(...)
>   {
>   ...
>   return (inb(handle + offset));
>   ...
>   }
> 
>   PC-98:
>   bus_space_read_1(...)
>   {
>   ...
>   return (inb(bsh.bsh_iat[offset]));
>   ...
>   }
> 
You could set the handle to point to the structure instead:
bus_space_read_1(...)
{
if (tag == I386_BUS_PIO) {
return (inb(handle + offset));
} else if (tag == I386_BUS_PIO_IND) {
struct bus_space_handle_pc98 *bsh = handle;
return (inb(bsh->bsh_iat[offset]));
} else if (tag == I386_BUS_MEMIO) {
...
}
}

-lq


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Learning the FreeBSD Kernel

[Sergey Babkin]

Mike Smith wrote:
> 
> Writing documentation is a resource-sucking nuisance; supporting outdated
> documentation even more so.  The BSD driver model is sufficiently simple

I think that there might be a compromise
solution: when someone learns the interface
from analysing the code he might as well document
his findings in some way for others to read.
This would require minor additional effort.
I'm going to try this with CAM in a few weeks
and see whether this idea is viable.

-SB


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Poweroff / power button in FreeBSD 3.3??

[Ralph Seguin]

Hi.
I'm having some difficulty getting APM and power control working in FreeBSD 3.3
I've built a kernel with APM enabled in the config file and enabled it in
rc.conf, however apmd says it's starting up, but ps never shows it running.

>From /etc/rc.conf:
apm_enable="YES"

bash-2.03# apm -s
apm: can't open /dev/apm: Device not configured

bash-2.03# ls -al apm*
crw-rw  1 root  operator   39,   0 Jan 21 15:24 apm
crw-rw  1 root  operator   39,   8 Jan 21 15:24 apmctl

What I'd like to do is have   shutdown  -p   work properly and I'd also like to
intercept the power switch so I can shutdown gracefully.

Any suggestions are much appreciated.

Thanks.
-Ralph
[EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

How to get a dynamically assigned major number?

[Archie Cobbs]

Dear kernel device gurus,

I'm trying to get the security/skip port working for 4.0.  Right
now it's marked BROKEN due to all the device changes earlier in
the year, and was wondering if someone could help advise me how do
update it..

Below is the current code that works with -stable.  How do I get
a major number for the cdevsw I need to add? It looks like cdevsw_add()
no longer treats zero as 'assign me one dynamically'.

I'd really like to get this fixed soon (ie, before 4.0).. I'm sure
it's something simple I'm missing.

Thanks!
-Archie

___
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com



-- excerpt from current code 

struct cdevsw skipdevsw = {
skip_ifopen, skip_ifclose, skip_ifread, skip_ifwrite, skip_ifioctl,
#if 0
nullstop, noreset, nodevtotty,
#endif
skip_ifpoll, nommap, nostrategy,
"skip", NULL
};

static struct cdevsw*old_dev;
static u_long   skip_major;

/*
 * Handle loading and unloading of the SKIP module.
 */
static int
skip_mod_event(module_t mod, int event, void *data)
{
int error = 0;
dev_t dev;

switch (event) {
case MOD_LOAD:

/* Add character device, getting assigned a major number */
dev = (dev_t) -1;
if ((error = cdevsw_add(&dev, &skipdevsw, &old_dev)) != 0) {
log(LOG_ERR, "skip: can't add device\n");
break;
}
skip_major = major(dev);

/* Initialize SKIP itself */
if ((error = skip_init()) != 0) {
/* XXX should remove char device */
log(LOG_ERR, "skip: init failed\n");
break;
}
log(LOG_INFO, "skip: device major=%lu, driver loaded\n",
skip_major);
break;

case MOD_UNLOAD:

/* Uninitialize SKIP */
if ((error = skip_uninit()) != 0) {
log(LOG_INFO, "skip: uninit failed\n");
break;
}

/* Replace original device driver (if any) */
dev = makedev(skip_major, 0);
(void) cdevsw_add(&dev, old_dev, NULL);
break;

default:
error = EOPNOTSUPP;
break;
}
return(error);
}

static moduledata_t skip_mod = {
"skip",
skip_mod_event,
NULL
};
DECLARE_MODULE(skip, skip_mod, SI_SUB_PROTO_END, SI_ORDER_MIDDLE);



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Performance issue with rfork() and single socketpairs versus multiple socketpairs.

[Brian Somers]

> "Scott Hess" wrote:
> 
> > I've found an odd performance issue that I cannot explain.  I'm using
> > socketpairs to communicate with multiple rfork(RFPROC) processes.
> 
> Use 'pipe(2)' rahter than 'socketpair(2)' as both are bidirectional and
> pipe is a LOT faster.

Although pipe(2)'s bi-directional capabilities are not standard (I've 
been stung by this in the past :-()

> Cheers,
> -Peter

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
     <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !  <[EMAIL PROTECTED]>




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Device Drivers

[Nathan Cohen]

I;d like to start contributing to the project, and I've heard unanimously a good place 
to start is device drivers. However, I'd like to try something other than sound cards 
(the only major recommendation I've heard so far) 

Are there any NICs, or other driver areas where FreeBSD could use some help?

Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: kern/13644

[Daniel Eischen]

On Mon, 24 Jan 2000, Matthew Dillon wrote:
> :
> :The "maximum interval to wait for the selection to complete" isn't
> :really the maximum, but more like the lower bounds of the time to
> :wait for the selection.
> :
> :Dan Eischen
> :[EMAIL PROTECTED]
> 
> It's definitely a maximum, because select() can return much sooner if
> one of the I/O events being waited on occurs.

It's not a maximum if you round up to the nearest clock tick.

> If you call it a minimum
> you imply that select() will not return until at least the specified 
> amount of time elapses, which is incorrect.  Just because it may go
> slightly over the specified time when no I/O events are pending does not
> change anything -- FreeBSD is not a hard-realtime system and programmers
> understand that.  If anyone were to actually get confused by this, they 
> have to go back to school.

I know all this, but I still prefer Solaris' wording over what we
have.  If someone is going to change the man page for this, then
I suggest we do it in a way that is more clear.  "system activity"
doesn't seem to me to cover rounding up to the nearest clock tick.
I'm happy with leaving the man page as it is also.

Dan Eischen
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Performance issue with rfork() and single socketpairs versus multiple socketpairs.

[Peter Wemm]

"Scott Hess" wrote:

> I've found an odd performance issue that I cannot explain.  I'm using
> socketpairs to communicate with multiple rfork(RFPROC) processes.

Use 'pipe(2)' rahter than 'socketpair(2)' as both are bidirectional and
pipe is a LOT faster.

Cheers,
-Peter



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: kern/13644

[Matthew Dillon]

:
:The "maximum interval to wait for the selection to complete" isn't
:really the maximum, but more like the lower bounds of the time to
:wait for the selection.
:
:Dan Eischen
:[EMAIL PROTECTED]

It's definitely a maximum, because select() can return much sooner if
one of the I/O events being waited on occurs.  If you call it a minimum
you imply that select() will not return until at least the specified 
amount of time elapses, which is incorrect.  Just because it may go
slightly over the specified time when no I/O events are pending does not
change anything -- FreeBSD is not a hard-realtime system and programmers
understand that.  If anyone were to actually get confused by this, they 
have to go back to school.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: kern/13644

[Daniel Eischen]

On Mon, 24 Jan 2000, Alfred Perlstein wrote:
> * Matthew Dillon <[EMAIL PROTECTED]> [000124 12:59] wrote:
> > 
> > :The manpage has been updated in -current:
> > :
> > : If timeout is a non-nil pointer, it specifies the maximum interval to
> > : wait for the selection to complete.  System activity can lengthen the in-
> > : terval by an indeterminate amount.
> > :
> > : If timeout is a nil pointer, the select blocks indefinitely.
> > :
> > : To effect a poll, the timeout argument should be non-nil, pointing to a
> > : zero-valued timeval structure.
> > :
> > :If no one objects I'll be committing it to -stable and praying to the
> > :gods that this thread dies.
> > :
> > :-Alfred
> > 
> > 'nil' ?  'nil' is the designation for an ascii 0, not a pointer.  
> > Please use 'null' or 'NULL' -- for example, look at the gettimeofday
> > man page.  'nil' has nothing to do with pointers.
> 
> I'll wait for more feedback and include this request in the final
> update, even if it's the only change.  'nil' doesn't cut it for me either.

I don't like the first stanza and prefer wording more like what Solaris
has for poll():

 If none of the defined events have occurred on any  selected
 file  descriptor, poll() waits at least 'timeout' milliseconds
 for an event to occur on any of the selected  file  descrip-
 tors. On a computer where millisecond timing accuracy is not
 available, 'timeout' is rounded up to the nearest legal  value
 available  on that system.

The "maximum interval to wait for the selection to complete" isn't
really the maximum, but more like the lower bounds of the time to
wait for the selection.

Dan Eischen
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Performance issue with rfork() and single socketpairs versus multiple socketpairs.

[Matthew Dillon]

:I've found an odd performance issue that I cannot explain.  I'm using
:socketpairs to communicate with multiple rfork(RFPROC) processes.
:Initially, I used a seperate socketpair to communicate requests to each
:...
:
:Unfortunately, I've found that having a group of processes reading from a
:group of socketpairs has better performance than having them all read from
:a single socketpair.  I've been unable to determine why.  I've reduced the
:problem down to a simple program, included as an attachment (sorry about
:that).  The results of two runs of the program:

The problem is that when you have N processes waiting on a single
socket and you write to the socket, all N processes will wake up even
though only one will get the data you wrote.

This is very similar to the select() problem -- N processes select()ing
on the same descriptor (typically a socket listen descriptor), new
connection comes in, all N processes are woken up even though only one's
accept() will succeed.

As an alternative to socket pairs, I would consider using SysV shared
memory and SysV semaphores.  Under -current you can use shared file
mmap()'s with MAP_NOSYNC as an alternative to using SysV shared memory,
but the SysV shared memory calls will be more portable.  ( When messing
with SysV shared memory the system utility 'ipcs -a' comes in useful ).

man -k shm
man ipcs

-Matt



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: kern/13644

[Matthew Dillon]

:> :
:> :-Alfred
:> 
:> 'nil' ?  'nil' is the designation for an ascii 0, not a pointer.
:> Please use 'null' or 'NULL' -- for example, look at the gettimeofday
:> man page.  'nil' has nothing to do with pointers.
:
:More correctly, 'nul' or 'NUL' are ASCII character 0.  'nil' is a pascal phrase
:that should *not* find its way into the general UNIX lexicon.
:
:-- 
:"Where am I, and what am I doing in this handbasket?"
:
:Wes Peters Softweyr LLC
:[EMAIL PROTECTED]   http://softweyr.com/

Ah, indeed!  nul/NUL == ascii.  'nil' should removed from our vocabulary.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: kern/13644

[Wes Peters]

Matthew Dillon wrote:
> 
> :The manpage has been updated in -current:
> :
> : If timeout is a non-nil pointer, it specifies the maximum interval to
> : wait for the selection to complete.  System activity can lengthen the in-
> : terval by an indeterminate amount.
> :
> : If timeout is a nil pointer, the select blocks indefinitely.
> :
> : To effect a poll, the timeout argument should be non-nil, pointing to a
> : zero-valued timeval structure.
> :
> :If no one objects I'll be committing it to -stable and praying to the
> :gods that this thread dies.
> :
> :-Alfred
> 
> 'nil' ?  'nil' is the designation for an ascii 0, not a pointer.
> Please use 'null' or 'NULL' -- for example, look at the gettimeofday
> man page.  'nil' has nothing to do with pointers.

More correctly, 'nul' or 'NUL' are ASCII character 0.  'nil' is a pascal phrase
that should *not* find its way into the general UNIX lexicon.

-- 
"Where am I, and what am I doing in this handbasket?"

Wes Peters Softweyr LLC
[EMAIL PROTECTED]   http://softweyr.com/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: kern/13644

[Wes Peters]

Mikhail Teterin wrote:
> 
> David Schwartz once wrote:
> 
> >  The  man page  is  correct  and the  implementation  is correct.
> 
> Several people, said the man pages are broken:
> 
> [...]
> 
> This is becoming ridiculous. Somehow, I  get a feeling a bunch of people
> manage  to agree  with  each other  on a  subject  they express  exactly
> opposite opinions.

So shut up and do something about it.  So far, we've seen everything *but*
patches for the man page from you.  Propose a better wording instead of
just throwing bricks.

-- 
"Where am I, and what am I doing in this handbasket?"

Wes Peters Softweyr LLC
[EMAIL PROTECTED]   http://softweyr.com/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: indirection in bus space

[Luoqi Chen]

> Do you have any comment anout the patch?  If there isn't any big
> problem, I hope to commit it to current.
> 
> Thank you.
> 
> 
> I wrote:
> > Do you remember this topic?  I have revised the indirection support
> > patch.  What I have changed are:
> >   - to make diff files more readable
> >   - introduce the bus_simple_create_bsh() that creates
> > a bus_space_handle_tag from a base address.
> > 
>
We shouldn't need bus_simple_create_bsh(). All drivers ought to use
rman_get_bushandle()/rman_get_bustag() to retrieve the bus handle and tag,
and use them in bus_space_read/write calls to perform device io. Drivers
that don't do that should be fixed.

Why have two files bus_at386.h and bus_pc98.h? I386_BUS_PIO_IND should be
able to live with I386_BUS_PIO and I386_BUS_MEMIO happily together.

-lq


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

routed config file

[thscalf]

The following is a sample of our existing network.What we need to happen is
all the traffic that is coming from eth2 ( being masq'ed) be sent out
router A, and all the rest out router B. Will routed do it, and how?

currently the default route is route B and therefore all the outbound
traffic goes there.

Thanks in advance,
Thad Scalf
RAF

--Network Picture-

|  |
|---| |-|
|  Router A | |  Router B   |
|  215.178.0.34 | | 40.15.125.250   |
|---| |-|
||
||
  |-|
  | eth3eth0|
|   215.178.0.3340.15.125.193   |
|   255.255.255.224 255.255.255.192 |
| |
|   Linux router  |
| |
| eth2  eth1  |
| eth2 - 215.178.0.3   eth1 - 40.15.125.1 |
|215.178.0.0/27   40.15.125.0/26  |
| eth2:1 - 192.168.0.2 eth1:0 - 40.15.125.65  |
|192.168.0.0/24   40.15.125.64/26 |
|-|
  |
  |
  |
Sub-networks routed and masq'ed from here.
  |
  |
215.178.0.64/26 gw 215.178.0.1 ( frame pipe to external networks)
  |
  |
10.0.0.0/16 gw 215.178.0.1
  |
  |
192.168.10.0/24 gw 215.178.0.1
  |
  |
192.168.20.0/24 gw 215.178.0.1
  |
  |
192.168.30.0/24 gw 215.178.0.1
  |
  |
   more networks will be added here...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: FreBSD 3.3, power off and power button stuff

[Ralph Seguin]

> 'dmesg | grep apm'
> If that returns nothing your kernel doesn't have APM
> in it. Check if
> you went through all the steps of compiling and
> installing a custom kernel.

Pretty sure I did all of this correctly.
Mr Brooks gave me a useful pointer: remove disable
from the apm config line.  I guess I should actually
READ what I'm doing... :-)

Here's what I've got:
cd /usr/src/sys/i386/conf
/usr/sbin/config -g TESTKERNEL
cd ../../compile/TESTKERNEL
make depend
make all
Then, I FTP'ed the kernel over to the test machine and
did the install line, by hand:

Pilfered from the kernel Makefile:
bash-2.03# cat kinst
#!/bin/sh

chflags noschg /kernel
mv /kernel /kernel.old
PATH=${PATH}:/sbin:/usr/sbin

if [ `sysctl -n kern.bootfile` = ${DESTDIR}/kernel ] ;
then
sysctl -w kern.bootfile=${DESTDIR}/kernel.old ;
if [ -f /var/db/kvm_kernel.db ] ; then
mv -f /var/db/kvm_kernel.db
/var/db/kvm_kernel.old.db
fi
fi

install -c -m 555 -o root -g wheel -fschg kernel /



> Or you might get something along the lines of 'apm0
> not found at .'
> in that case your BIOS doesn't have APM enabled. (if
> it supports it at all)

It's an Intel i810E motherboard which has APM support.

Apparently other people have had trouble with shutdown
-p not working in 3.x kernels.  Unfortunately, I don't
have the option of going to -current, so I need to get
it going in 3.3-RELEASE.


What files are involved in APM and power control?

Would it be easy to produce a patch to merge in to 
3.3-RELEASE?

Does anyone have shutdown -p / halt -p  working in
3.3-RELEASE?

Reading the LINT kernel config file, it mentions VM86
being related to apm?  Should I be turning this option
on (I'm going to try that as an experiment soon)?

Thanks.
-Ralph
[EMAIL PROTECTED]


__
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: kern/13644

[Alfred Perlstein]

* Matthew Dillon <[EMAIL PROTECTED]> [000124 12:59] wrote:
> 
> :The manpage has been updated in -current:
> :
> : If timeout is a non-nil pointer, it specifies the maximum interval to
> : wait for the selection to complete.  System activity can lengthen the in-
> : terval by an indeterminate amount.
> :
> : If timeout is a nil pointer, the select blocks indefinitely.
> :
> : To effect a poll, the timeout argument should be non-nil, pointing to a
> : zero-valued timeval structure.
> :
> :If no one objects I'll be committing it to -stable and praying to the
> :gods that this thread dies.
> :
> :-Alfred
> 
> 'nil' ?  'nil' is the designation for an ascii 0, not a pointer.  
> Please use 'null' or 'NULL' -- for example, look at the gettimeofday
> man page.  'nil' has nothing to do with pointers.

I'll wait for more feedback and include this request in the final
update, even if it's the only change.  'nil' doesn't cut it for me either.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: kern/13644

[Matthew Dillon]

:The manpage has been updated in -current:
:
: If timeout is a non-nil pointer, it specifies the maximum interval to
: wait for the selection to complete.  System activity can lengthen the in-
: terval by an indeterminate amount.
:
: If timeout is a nil pointer, the select blocks indefinitely.
:
: To effect a poll, the timeout argument should be non-nil, pointing to a
: zero-valued timeval structure.
:
:If no one objects I'll be committing it to -stable and praying to the
:gods that this thread dies.
:
:-Alfred

'nil' ?  'nil' is the designation for an ascii 0, not a pointer.  
Please use 'null' or 'NULL' -- for example, look at the gettimeofday
man page.  'nil' has nothing to do with pointers.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: kern/13644

[Alfred Perlstein]

* Mikhail Teterin <[EMAIL PROTECTED]> [000124 12:35] wrote:
> David Schwartz once wrote:
> 
> >  The  man page  is  correct  and the  implementation  is correct.
> 
> Several people, said the man pages are broken:
> 
>   Bruce Evans on Dec 28:
>   > If timeout is a  non-nil pointer, it specifies
>   > a maximum  interval to wait for  the selection
>   > to complete.
> 
>   This is a  bug in the man page. It  is so poorly
>   worded that  it is broken. "maximum"  here means
>   "minimum" in  the case  where no  selected event
>   occurs.
> 
>   Daniel Eischen on Jan 23:
>   You have  to guarantee  that the actual  time is
>   greater  than or  equal  to the  amount of  time
>   specified.
> 
>   Warner Losh on Jan 23:
>   : Could you provide  the chapter/verse number of
>   : where POSIX spec contradicts the man pages? It
>   : will help  me make my  case on the  TCL forum,
>   : since  the  TCL  developers remain  under  the
>   : mistaken assumption, that  select() may return
>   : earlier, but never later than specified.
> 
>   Somewhere in the archives  have a pointer to the
>   unified unix spec for select. Might want to look
>   for  it. A  useful regular  expression might  be
>   http://www.*/select.*.
> 
> This is becoming ridiculous. Somehow, I  get a feeling a bunch of people
> manage  to agree  with  each other  on a  subject  they express  exactly
> opposite opinions.

The manpage has been updated in -current:

 If timeout is a non-nil pointer, it specifies the maximum interval to
 wait for the selection to complete.  System activity can lengthen the in-
 terval by an indeterminate amount.

 If timeout is a nil pointer, the select blocks indefinitely.

 To effect a poll, the timeout argument should be non-nil, pointing to a
 zero-valued timeval structure.

If no one objects I'll be committing it to -stable and praying to the
gods that this thread dies.

-Alfred


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

RE: kern/13644

[David Schwartz]

> =The man pages say exactly:
> = If timeout is  a non-nil pointer, it specifies  a maximum interval
> = to wait for the selection to complete.

> =Which doesn't say that it will sleep no more than this. It says that it
> =will wait no longer than this for the selection to complete. It doesn't
> =guarantee  anything,  imho.  It  doesn't guarnatee  that  you  will  be
> =scheduled at any given time.

> Yep.  But that  little, that  I was  told of  implementation, says  that
> the  rounding  up is  there  to  guarantee the  sleep  of  no less  then
> specified. This  is consistent  with my  experiments, which  show steady
> 9-10 milliseconds extra sleeping time.

The man page is correct and the implementation is correct. The purpose of
the timeout field in select is to specify the longest you want to wait. The
implementation guarantees that it will wait at least that long if it needs
to.

It's like if I asked my wife to wait for a UPS package to arrive starting
now. And she says, "what's the maximum I need to wait", and I say "4 hours".
She's complying with my request if she waits for at least 4 hours, right?
The term "maximum" refers to the fact that she can stop waiting earlier if
the package arrives. It doesn't mean she can't wait more than 4 hours.

DS



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: kern/13644

[Mikhail Teterin]

David Schwartz once wrote:

>  The  man page  is  correct  and the  implementation  is correct.

Several people, said the man pages are broken:

Bruce Evans on Dec 28:
> If timeout is a  non-nil pointer, it specifies
> a maximum  interval to wait for  the selection
> to complete.

This is a  bug in the man page. It  is so poorly
worded that  it is broken. "maximum"  here means
"minimum" in  the case  where no  selected event
occurs.

Daniel Eischen on Jan 23:
You have  to guarantee  that the actual  time is
greater  than or  equal  to the  amount of  time
specified.

Warner Losh on Jan 23:
: Could you provide  the chapter/verse number of
: where POSIX spec contradicts the man pages? It
: will help  me make my  case on the  TCL forum,
: since  the  TCL  developers remain  under  the
: mistaken assumption, that  select() may return
: earlier, but never later than specified.

Somewhere in the archives  have a pointer to the
unified unix spec for select. Might want to look
for  it. A  useful regular  expression might  be
http://www.*/select.*.

This is becoming ridiculous. Somehow, I  get a feeling a bunch of people
manage  to agree  with  each other  on a  subject  they express  exactly
opposite opinions.

-mi


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: kern/13644

[Warner Losh]

In message <01bf669f$94c4ec70$[EMAIL PROTECTED]> "David Schwartz" writes:
: The term "maximum" refers to the fact that she can stop waiting earlier if
: the package arrives. It doesn't mean she can't wait more than 4 hours.

Exactly.  She's not letting you down by waiting 5 hours before giving
up, or going somewhere else for an hour after the 4 hours are up and
then phoning you to say that there was no package.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Learning the FreeBSD Kernel

[Warner Losh]

In message <[EMAIL PROTECTED]> Jeroen Ruigrok/Asmodai 
writes:
: So my statement was actually more in reflection to NetBSD's support of
: it.  Whether or not they support busses which do 8 byte atomic
: reads/writes I am not sure of.
: 
: Thanks for the reality adjustment Warner. =)

Yes.  Looking at the bus.h in NetBSD/i386 I see:

#if 0   /* Cause a link error for bus_space_read_8 */
#define bus_space_read_8(t, h, o)   !!! bus_space_read_8 unimplemented !!!
#endif

The Netbsd/alpha version appears to have it defined.  Makes sense when
you think about it.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Learning the FreeBSD Kernel

[Jeroen Ruigrok/Asmodai]

-On [2124 19:55], Warner Losh ([EMAIL PROTECTED]) wrote:
>In message <[EMAIL PROTECTED]> Jeroen Ruigrok/Asmodai 
>writes:
>: >As long as a device is just inb/outb (I seem to recall newbus have a
>: >replacement for these)
>: 
>: bus_space_read_#() / bus_space_write_#()
>: 
>: Where # is 1, 2, 4, or 8.  But I don't think we support atomic 8 byte
>: atomic reads and writes.
>
>It isn't so much that "we" don't support atomic 8 byte operations, it
>is that the busses and cpus don't support these operations...

Sorry, mea culpa.  It's just that I have been shifting back and forth
between NetBSD and FreeBSD and that I see they have
bus_space_[read|write]_8 defined and we don't.

So my statement was actually more in reflection to NetBSD's support of
it.  Whether or not they support busses which do 8 byte atomic
reads/writes I am not sure of.

Thanks for the reality adjustment Warner. =)

-- 
Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/B-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
Woe to the vanquished!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Warning: xxx sector(s) in last cylinder unallocated

[Zhihui Zhang]

The message comes when you create a new filesystem with newfs.  According
to page 263 of the "The complete FreeBSD", this is not a problem because
the space will be used anyway (how?).

I searched the archive, somebody mentioned an option to newfs to use the
unallocated space.  My understanding is that if there are no bits in the
bitmaps corresponding to those sectors, they will never be used. If there
are, why newfs prints the warning message?

I hope someone will clarify this for me. Thanks a lot.

-Zhihui



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Learning the FreeBSD Kernel

[Warner Losh]

In message <[EMAIL PROTECTED]> Jeroen Ruigrok/Asmodai writes:
: >As long as a device is just inb/outb (I seem to recall newbus have a
: >replacement for these)
: 
: bus_space_read_#() / bus_space_write_#()
: 
: Where # is 1, 2, 4, or 8.  But I don't think we support atomic 8 byte
: atomic reads and writes.

It isn't so much that "we" don't support atomic 8 byte operations, it
is that the busses and cpus don't support these operations...

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Performance issue with rfork() and single socketpairs versus multiple socketpairs.

[Scott Hess]

I've found an odd performance issue that I cannot explain.  I'm using
socketpairs to communicate with multiple rfork(RFPROC) processes.
Initially, I used a seperate socketpair to communicate requests to each
process, with locking in the parent to synchronize access to each client.
I determined that by using a single socketpair, I could save on all the
socketpairs, and also perhaps improve performance by allowing more requests
to be dispatched than there were processes to handle them.  Whenever a
worker process finished one request, it would immediately be able to start
the next, without having to wait for the parent to receive the response and
reprocess the request structures.

Unfortunately, I've found that having a group of processes reading from a
group of socketpairs has better performance than having them all read from
a single socketpair.  I've been unable to determine why.  I've reduced the
problem down to a simple program, included as an attachment (sorry about
that).  The results of two runs of the program:

ganja% time ./commtest --single
./commtest --single  0.00s user 0.66s system 15% cpu 4.132 total
ganja% time ./commtest --multi
./commtest --multi  0.00s user 0.46s system 68% cpu 0.675 total

Note that in the --single case, the system time rises a bit - but the
wallclock time rises a _lot_.  At first I thought this was a variant on the
"thundering herd" problem, but the CPU times taken don't seem to bear this
out.

Any ideas?  Running under 3.2-RELEASE on an SMP machine, though I saw the
same results on 3.4-RELEASE.

Thanks,
scott


 commtest.c

Re: perfmon

[Dan Nelson]

In the last episode (Jan 24), Gustavo Rios said:
> I have enabled perfmon options in my kernel config file, to be able
> to monitor my system performance.

The perfmon kernel option lets you read the Pentium/P6 hardware
counters.  It has nothing to do with Solaris's perfmeter, which
probably uses a proprietary protocol anyway.

You might want to take a look at xosview, xperfmon3, xsysinfo, or
xsysstats in the ports tree.

-- 
Dan Nelson
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Learning the FreeBSD Kernel

[Jeroen Ruigrok/Asmodai]

-On [2124 08:01], Chuck Robey ([EMAIL PROTECTED]) wrote:
>
>The problem is, you can't even find what the interfaces are.  Reading the
>code isn't very useful if you can't even find the right place to start
>from.  At least the interface points could be listed, so that someone
>would know where to begin.

Working on that.

And I am finally getting somewhere.  I hope to commit some manpages,
very rough for now, somewhere this week.

-- 
Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/B-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
We've laid together in the sun before the mind-rape has begun...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

perfmon

[Gustavo Rios]

Hi!

I have enabled perfmon options in my kernel config file, to be able to
monitor my system performance.

I am trying to do so through a sun box running perfmeter v3.5.1, but all i
get is small pict that ressembles a lock with the following word: RIP.

I have enable portmap (cause perfmeter uses it).

The problem, is that there nothing being showed in my sun box.

Can anyone here give a littler help?

Thanks a lot for your time and cooperation.

--
The thing i like most about Windows is 
You can download FreeBSD with it!



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [PATCH] Please test the PS/2 mouse driver patch

[Kazutaka YOKOTA]

>I have the Logitech wireless radio mouse, and I get errors about illegal or
>unknown PS/2 packets. It's cosmetic, because the mouse works like a charm,
>but the very first mouse click or move makes it jump across the screen.
>After that

Please provide the following information so that I can diagnose your
problem.

1. Which version of FreeBSD you are using.
2. EXACT product name and the model # of your Logitech mouse.
   You see, Logitech has produced quite a lot of mice. You can find
   the name and the model # printed on the label on the bottom surface
   of the mouse.
3. EXACT error messages you saw. Check /var/log/messages.  The error
   messages may still be there.
4. If you are using FreeBSD 3.X, send me /var/run/dmesg.out and /etc/rc.conf
   so that I can see how your mouse is set up.
5. If you are describing error when you are using XFree86, send me
   your XF86Config file too, and tell me the version number of XFree86.

Kazu

>Does this fix address that problem too?
>
>If not, could I get you to address this problem? :-)
>
>Kees Jan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Learning the FreeBSD Kernel

[Jeroen Ruigrok/Asmodai]

-On [2124 10:13], William A. Maniatty ([EMAIL PROTECTED]) wrote:

>Is it possible to get a look at the digital Unix guides, that might be a
>good starting point.  Are they on line (perhaps you have a URL)?

http://www.unix.digital.com/faqs/publications/dev_doc/DOCUMENTATION/HTML/Digital_UNIX_Bookshelf.html

-- 
Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/B-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
But Time, keeps flowing like a river (on and on)...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Learning the FreeBSD Kernel

[Jeroen Ruigrok/Asmodai]

-On [2124 10:13], Daniel C. Sobral ([EMAIL PROTECTED]) wrote:

>As long as a device is just inb/outb (I seem to recall newbus have a
>replacement for these)

bus_space_read_#() / bus_space_write_#()

Where # is 1, 2, 4, or 8.  But I don't think we support atomic 8 byte
atomic reads and writes.

-- 
Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/B-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
When we have not what we like, we must like what we have...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: FreBSD 3.3, power off and power button stuff

[ROGIER MULHUIJZEN]

A few things here. apmd is not the same as apm. So check your
/etc/rc.conf to see if you have both apm_enable and apmd_enable set to
"YES". apmd is just a daemon to take care of some apm events, but for
shutdown -p it's not needed.

Try 'apmconf -e' on the command line.

If you still get 'apm: can't open /dev/apm: Device not configured' do
'dmesg | grep apm'
If that returns nothing your kernel doesn't have APM in it. Check if
you went through all the steps of compiling and installing a custom
kernel.

Or you might get something along the lines of 'apm0 not found at .'
in that case your BIOS doesn't have APM enabled. (if it supports it at
all)

Let me know if this helps at all

  DocWilco

>>> Ralph Seguin <[EMAIL PROTECTED]> 01/22 12:43 AM >>>
Hi.
I'm having some difficulty getting APM and power
control working in FreeBSD 3.3
I've built a kernel with APM enabled in the config
file and enabled it in
rc.conf, however apmd says it's starting up, but ps
never shows it running.

>From /etc/rc.conf:
apm_enable="YES"

bash-2.03# apm -s
apm: can't open /dev/apm: Device not configured

bash-2.03# ls -al apm*
crw-rw  1 root  operator   39,   0 Jan 21 15:24
apm
crw-rw  1 root  operator   39,   8 Jan 21 15:24
apmctl

I did a MAKEDEV in /dev, just in case, but the
major/minor numbers came out the same.

What I'd like to do is have   shutdown  -p   work
properly and I'd also like to
intercept the power switch so I can shutdown
gracefully.

Any suggestions are much appreciated.

Thanks.
-Ralph
[EMAIL PROTECTED] 

__
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com 


To Unsubscribe: send mail to [EMAIL PROTECTED] 
with "unsubscribe freebsd-hackers" in the body of the message


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: FreBSD 3.3, power off and power button stuff

[Kris Kirby]

> I don't know how you would catch the power switch.  If you could tell it
> apart from other methods of generating teh same APM event you could
> probably do it with apmd.  Otherwise you'll need ACPI support which IIRC
> will start coming in to -current after -current becomes 5.0 (within the
> next few months).

My Abit BP6 has an option in BIOS (under power management) to "Power
Button Override". IIRC, this is an ACPI function. 


Kris Kirby, KE4AHR  | TGIFreeBSD... 'Nuff said.
<[EMAIL PROTECTED]>|
---
"God gave them the ability to reproduce...
... Science gave us the hope they won't." -KBK



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

BPF bug or not?

[Yevmenkin, Maksim N, CSCIO]

All,

I've just found that read from /dev/bpfX never return EAGAIN/EWOULDBLOCK.
It means that when you do a non blocking read and there is no data you will
always get 0.

Does it suppose work this way?

A non blocking read from pipe return EAGAIN/EWOULDBLOCK if there is no data
and
pipe was opened as O_RDWR, and 0 when pipe was opened as O_RDONLY.

Thanks,
emax


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

RE: [PATCH] Please test the PS/2 mouse driver patch

[Koster, K.J.]

> 
> I wrote a patch for the psm driver to add support for several 
> PS/2 mice.
> It is in http://www.freebsd.org/~yokota/ps2mice-24Jan2000.tar.gz.
> I am attaching README included in the patch.
> 
I have the Logitech wireless radio mouse, and I get errors about illegal or
unknown PS/2 packets. It's cosmetic, because the mouse works like a charm,
but the very first mouse click or move makes it jump across the screen.
After that

Does this fix address that problem too?

If not, could I get you to address this problem? :-)

Kees Jan

==
 You are only young once,
  but you can stay immature all your life


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Learning the FreeBSD Kernel

[Mike Smith]

> On Sun, 23 Jan 2000, Mike Smith wrote:
> 
> > > I can't agree with Mike Smith that reading the code is adequate.  It
> > > certainly doesn't apply to newcomers, but it doesn't even apply to
> > > seasoned hackers like Mike: the BSD style doesn't provide for adequate
> > > comments, and so what you see from the code is mainly tactics, not
> > > strategy.
> > 
> > You miss my point; you don't want to be writing a driver until you know 
> > what you're doing.  Documentation on an OS' driver interface won't teach 
> > you that; it's something that's really only ever gleaned from experience.
> 
> The problem is, you can't even find what the interfaces are.  Reading the
> code isn't very useful if you can't even find the right place to start
> from.  At least the interface points could be listed, so that someone
> would know where to begin.

Listing the interface points won't help unless you know which ones are 
relevant to what you're trying to do.  I say it again; first you need to 
know how to write a device driver, then you need to know what the 
available tools are to get the job done.  Having only the latter does 
not help at all with the former.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Sorry

[Stefano Riva]

  Sorry for my previous message. It was simply an error. I need more
sleeping. :-)

---

  Stefano Riva
  Systems & Network Administrator
  Informazioni Editoriali I.E. Srl
  Voice +39-02283151, Fax +39-0228315900



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Prova hackers

[Stefano Riva]

  Ehila'. Chi mi riceve?

---

Stefano Riva
[EMAIL PROTECTED]
Gruppo Utenti FreeBSD Italiani
http://www.gufi.org



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Learning the FreeBSD Kernel

[Jeroen Ruigrok/Asmodai]

-On [2124 10:13], Daniel C. Sobral ([EMAIL PROTECTED]) wrote:
>Bill Maniatty wrote:
>> 
>> First we want to get the mechanism of driver installation down, then
>> try our hands at writing our own driver.  I fear that if we roll our own
>> driver software we may find that if we have errors (not that we ever have
>> errors mind you :-) we may not be able to isolate the cause.  This is
>> why I was leaning towards reinstalling a working driver first.
>
>You won't have any trouble at all with basic driver installation. In
>fact, this is driver skeleton, that can be templated (and used to... but
>I don't know if we have newbus templates or not).

man 9 driver.

>Notice that most developers use kld to develop their drivers. Not having
>to recompile the kernel and reboot really helps. :-) There exists one
>tutorial-style guide to writing kld's. It's a "hacking" guide to the use
>of kld's as a way to introduce back-doors in FreeBSD, and though it's
>somewhat "unclean" wrt to interface description, it's an effective
>tutorial. I'm sure it can be found from FreeBSD's web site.

Trust me, writing modules is the _least_ of your worries.  If I can
write a module then every^H^H^H^H^Hcluefull people can. =)

/usr/src/sys/modules

>As a next step, I suggest writing "virtual" drivers, not bound to any
>hardware. There are many such drivers in the tree. As a trivial example,
>and a favorite of many, the screen savers.
>
>The above will get you proficient with the basics of writing device
>drivers, but still leave a lot out. Let's see...

[Not looking at the source code for those I dare say:] But they are not
using any busspace/newbus functionality for all I know.  And cannot be
compared to the `real' drivers IMHO.

>> How mature is the USB driver technology?  If it is pretty preliminary
>> we may wish to visit that later.  Please recall that we are on a learning
>> curve here.
>
>If we support ethernet cards on USB, I'd say it's pretty mature. :-)
>
>Anyway, here is what virtual drivers won't teach: how to get resources,
>which will vary from bus to bus, how to interact with some of the kernel
>subsystems... How does one write a tun device? How does one write a
>network device? How does one write a network protocol? How does one
>write a CAM device (more than one type exist -- some virtual and some
>not)? How does one write a bus device? When to write a bus (newpcm uses
>a bus of it's own, if I'm not mistaken)?

If you refer to pcm attaching to sbc or gusc.  But those are pseudo
busses if I understood everything correctly, the same goes for miibus
and related busses (ppbus, smbus, iicbus).

>These problems are mostly distinct from each other, and their usefulness
>varies. Certainly, a tutorial covering newbus and the main bus types
>(usb, isa, pci) would be useful and not too difficult to write. CardBus
>and PCMCIA would be very useful, but we'll have to finish that first
>:-). 

Ehm, a tutorial covering the bus types.  You have no idea how much you
can write about ISA and PCI alone.

>But it gets complicated from there on. Writing a tutorial on even a
>subsection of CAM would be very time-consuming.

Write a reference so that we can finally convert the last drivers to
CAM/newbus. =)

>Julian had a device skeleton generator way back, I don't know if there
>is a newbus equivalent or not.

I think Peter [Wemm] wrote a skeleton one.

>Documenting the available debugging tools and useful debugging
>techniques would be mostly welcome. Aside from "how do I use the kernel
>debugger", use of tools such as truss, and loading symbol tables to
>kld's (see Greg Lehey's documentation on debugging vinum) would be
>useful tutorials.

Yeah yeah, coming up.  Stop whining. ;)
Hey, wait a sec, you said yesterday that you were bored.  Nice task for
you DCS ;)

-- 
Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/B-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
Ain't gonna spend the rest of my Life, quietly fading away...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

[PATCH] Please test the PS/2 mouse driver patch

[Kazutaka YOKOTA]

I wrote a patch for the psm driver to add support for several PS/2 mice.
It is in http://www.freebsd.org/~yokota/ps2mice-24Jan2000.tar.gz.
I am attaching README included in the patch.

Thank you.

Kazu

--
PS/2 mouse driver patch for 4.0-CURRENT
24 January 2000
Kazutaka YOKOTA, [EMAIL PROTECTED]

This patch adds support for the following PS/2 mice to the psm driver.

- Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons
  and a wheel which also acts as the middle button.
- Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a
  wheel which also acts as the middle button.
- MouseSystems SmartScroll Mouse: 3 buttons on top, 1 side button and
  a wheel.
- IBM ScrollPoint: 2 buttons on top and a stick between the buttons.
  (The stick can perform "horizontal scroll" in W*ndows environment.
  The horizontal movement of the stick is detected, but is quietly 
  ignored by the psm driver, as we don't have framework to support it.)

There are two diff files:

ps2mice.diff
moused.diff

Apply them to 4.0-CURRENT as follows:

cd /sys/isa
patch < ps2mice.diff
cd /usr/src/usr.sbin/moused
patch < moused.diff

Rebuild the kernel and moused.  (Note that you need to copy
/sys//include/mouse.h to /usr/include/machine/mouse.h before
you rebuild moused.)

The following is the list of files modified by this patch.

/sys/alpha/include/mouse.h
/sys/dev/kbd/atkbdcreg.h
/sys/i386/include/mouse.h
/sys/isa/psm.c
/usr/src/usr.sbin/moused/moused.c

This patch is for 4.0-CURRENT.  Although I personally have not tested
yet, I expect you can apply it to 3.4-STABLE without much difficulty.
(FYI, /sys/isa/psm.c is for alpha only in 3.4-STABLE. psm.c for i386 
is in /sys/i386/isa in 3.4-STABLE.)

Kazu
--


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Better fixit (was: Why was rsh removed from the fixitfloppy?)

[ROGIER MULHUIJZEN]

>I just want to correct one misunderstanding. 'The Hobbit' is the author
of
>netcat, not l0pht.

Ack! I thought he was part of l0pht my apologies for any
inaccuracy.

I still stand by that either netcat or socket (which I hear does pretty
much the same) should be included.

/me jumps on -small

 DocWilco


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Learning the FreeBSD Kernel

[Jeroen Ruigrok/Asmodai]

-On [2124 08:01], Mike Smith ([EMAIL PROTECTED]) wrote:
>> I can't agree with Mike Smith that reading the code is adequate.  It
>> certainly doesn't apply to newcomers, but it doesn't even apply to
>> seasoned hackers like Mike: the BSD style doesn't provide for adequate
>> comments, and so what you see from the code is mainly tactics, not
>> strategy.
>
>You miss my point; you don't want to be writing a driver until you know 
>what you're doing.  Documentation on an OS' driver interface won't teach 
>you that; it's something that's really only ever gleaned from experience.

This I agree on with Mike.  Writing device drivers isn't like writing an
application.

The documentation I am writing will definately not be a tutorial style
piece of documentation, but a reference guide with sufficient background
material so that people a bit familiar with FreeBSD on source level
(note the ``a bit'') will get enough ideas and clues from it to proceed
forwards.

I do not think making it a tutorial will be beneficial in the long run,
since I would have to discuss kernel sources, gdb, ddb and a number of
other things on the side.  But then again we will see where we will end.

I just know, from experience, that writing a driver involves more than
just code.

-- 
Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/B-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
Ain't gonna spend the rest of my Life, quietly fading away...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: kern/13644

[Bruce Evans]

On Sun, 23 Jan 2000, Warner Losh wrote:

> : This is what I asked for,  when I asked for "other specification". Could
> : you provide the chapter/verse number of where POSIX spec contradicts the
> : man pages? It will help me make my  case on the TCL forum, since the TCL
> : developers  remain  under the  mistaken  assumption,  that select()  may
> : return earlier, but never later than specified.
> 
> That's trivially easy to show.

In theory, but not in practice :-).

> Given process X with a priority N + 1 that is doing
  N - 1 (higher priority is actually "lower")
>   while (1) ;
> while process Y with a priority of N is doing the select.  The kernel
> won't prempt X until the time slice is done, which can be a long
> time.  If the select'd process is swapped out, then it could take a
> very very long time to swap back in.

Um, if the priorities are actually N vs. N - 1, then the process with
priority N won't run at the end of the timeslice.  It will only run
when its priority becomes "lower", possibly several timeslices later.

In practice, the priorities will never be N vs. N - 1.  The process
doing the select() sleeps at priority PSOCK = 24.  The process doing
the while loop should always have priority >= PUSER = 50, but due to
a bug (?) in nice(2), the priority of a nice --20 process can be as
low as PUSER - 20 = 30.  Anyway, that is > PSOCK, so the process doing
the select() will preempt the user process and wake up as soon as it
times out.  Then, due to a longstanding scheduling bug (?), the process
doing the select() will return to userland without being rescheduled,
although its user priority may be much "higher" than that of any other
runnable process.  Processes that do i/o are thus preferred to cpu
hogs much more strongly than their priorities indicate.  This bug is
a feature in most cases.  It reduces context switches.  Interactive
process may get more benefit from it than from the classical scheduling
preference for interactive processes.

Bruce



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Better fixit (was: Why was rsh removed from the fixit floppy?)

[Andrzej Bialecki]

On Sun, 23 Jan 2000, Kris Kennaway wrote:

> On Mon, 24 Jan 2000, Peter Jeremy wrote:
> 
> > On Fri, 21 Jan 2000 18:01:34 +0530, Greg Lehey <[EMAIL PROTECTED]> wrote:
> > >If you want a better fixit floppy, you should consider the new custom
> > >disk pair with PicoBSD ...  There's still space on there; what
> > >else could we put there?
> > 
> > ssh or OpenSSH (though this might cause distribution problems - how did
> > Jordan's visit to WC's Counsel go?)
> 
> Unfortunately openssh is quite a bit bigger than the standard ssh, because
> openssl isn't exactly the slimmest crypto library in the world :-) But, it
> would definitely be a cool thing.

Feel invited to visit freebsd-small, where we discuss now future
directions for small floppy-based setups (which include installation disks
as well).

Andrzej Bialecki

//  <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Learning the FreeBSD Kernel

[Daniel C. Sobral]

Bill Maniatty wrote:
> 
> First we want to get the mechanism of driver installation down, then
> try our hands at writing our own driver.  I fear that if we roll our own
> driver software we may find that if we have errors (not that we ever have
> errors mind you :-) we may not be able to isolate the cause.  This is
> why I was leaning towards reinstalling a working driver first.

You won't have any trouble at all with basic driver installation. In
fact, this is driver skeleton, that can be templated (and used to... but
I don't know if we have newbus templates or not).

Notice that most developers use kld to develop their drivers. Not having
to recompile the kernel and reboot really helps. :-) There exists one
tutorial-style guide to writing kld's. It's a "hacking" guide to the use
of kld's as a way to introduce back-doors in FreeBSD, and though it's
somewhat "unclean" wrt to interface description, it's an effective
tutorial. I'm sure it can be found from FreeBSD's web site.

As a next step, I suggest writing "virtual" drivers, not bound to any
hardware. There are many such drivers in the tree. As a trivial example,
and a favorite of many, the screen savers.

The above will get you proficient with the basics of writing device
drivers, but still leave a lot out. Let's see...

> > Definately not an ethernet card. *g*
> > Seems no-one can keep up with Bill Paul in that aspect. =)
> 
> We probably could not compete :-), but we are interested in ethernet
> card drivers (at some point) and would like to learn.
> 
> > You could try usb devices and contact Nick Hibma for his expertise on
> > that area.
> 
> How mature is the USB driver technology?  If it is pretty preliminary
> we may wish to visit that later.  Please recall that we are on a learning
> curve here.

If we support ethernet cards on USB, I'd say it's pretty mature. :-)

Anyway, here is what virtual drivers won't teach: how to get resources,
which will vary from bus to bus, how to interact with some of the kernel
subsystems... How does one write a tun device? How does one write a
network device? How does one write a network protocol? How does one
write a CAM device (more than one type exist -- some virtual and some
not)? How does one write a bus device? When to write a bus (newpcm uses
a bus of it's own, if I'm not mistaken)?

These problems are mostly distinct from each other, and their usefulness
varies. Certainly, a tutorial covering newbus and the main bus types
(usb, isa, pci) would be useful and not too difficult to write. CardBus
and PCMCIA would be very useful, but we'll have to finish that first
:-). 

But it gets complicated from there on. Writing a tutorial on even a
subsection of CAM would be very time-consuming. I assume the same can be
said of network devices in general. It will probably not be viable to
cover more than one such subject, and their usefulness would be somewhat
restricted. On the other hand, it is precisely this kind of tutorial
that is mostly needed, since all of what I mentioned before can be dealt
with on the fly, just by copying source from existing devices.



Now... let me see if I can recall some of the gotcha's (notice that I
have never written a newbus device driver). Writing a device driver to
exotic devices, as long as you have the documentation for it, is really
simple. It's when you have to interact to kernel subsystems that
steepens the learning curve. Getting a MYDEVICE into memory is trivial.
Just steal the skeleton from the source of some existing device. Julian
had a device skeleton generator way back, I don't know if there is a
newbus equivalent or not.

As long as a device is just inb/outb (I seem to recall newbus have a
replacement for these), things are mostly trivial. Covering what you can
and cannot do in an interrupt context, the exact working of our spl*()
functions (not just theory, but the practice of when to use them and
when not to), transfering data to/from user space, setting up dma
transfers, and what exactly happens in a tsleep() (DURING the tsleep(),
mind you :) are the FAQs, I think. Also, how to create a kernel thread
to lighten the load on the interrupt handler (ie, queue work to be done
outside the interrupt context) would be very useful too, and it's not
too much black magic.

Documenting the available debugging tools and useful debugging
techniques would be mostly welcome. Aside from "how do I use the kernel
debugger", use of tools such as truss, and loading symbol tables to
kld's (see Greg Lehey's documentation on debugging vinum) would be
useful tutorials.

Once you got the above, and possibly created some useful driver
templates in the process, I'd say choose a subsystem, and start some
in-depth tutorial. Stay away from FS work, as our interfaces are bound
to change. CAM is very stable, and SCSI drivers are always useful, so
that's one possible field. Network devices would probably take less
time, though (that's a wild guess on my part, though).

--
Daniel C. Sobral 

Parallel port problems... solved! (maybe)

[Ronald F. Guilmette]

A few weeks ago, I showed up here and was bitching about not being able
to send stuff out to my parallel printer.

I got a bit of heat for saying that I _could_ send data to the printer
from my other system (running Linux).

Well, I just wanted to say that all indications now are that the FreeBSD
kernel and the FreeBSD parallel port driver have been vindicated.

I recently loaded up FreeBSD on that other system and guess what?  I can
print just fine from that now.  Conclusion:  It ain't the software.

As far as I can tell now, the real problem is/was due to something... I'm
not sure exactly what... which is rather non-normal about the on-motherboard
parallel port hardware on _this_ specific motherboard, namely, a Tekram
model P5V30-B4.

But over on my other system that has an ASUS P5A, I got no problems at
all printing under either Linux or FreeBSD.

I tried to track down the problem with the parallel port hardware on this
Tekram P5V30-B4 by throwing a few printfs into the FreeBSD parallel port
driver but I didn't get very far... just far enough to see that the parallel
port hardware on this (Tekram) board seems to be *really* either broken or
else substantially different from what the parallel port driver is expecting.
Almost anything the driver did to the on-board parallel port caused that
port to come back with the nACK bit set in its status register, and
apparently, the driver didn't like that much. :-)

I just wanted to set the record straight on this.  It was definitely not
FreeBSD's fault, as far as I can see now.

Has anyone ever used FreeBSD to drive a parallel port on a Tekram p5V30-B4?


P.S.  Actually, that other (ASUS P5A) system inherited a disk drive that
had FreeBSD 3.1 loaded up on it, and that appears to be using the `nlpt'
driver, rather than the `lpt' driver that is being used on this (3.3)
system on the Tekram.  But I don't believe that is relevant.  The errors
I was seeing seemed to be happening at a lower (ppbus) level.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Learning the FreeBSD Kernel

[Matthew N. Dodd]

On Mon, 24 Jan 2000, William A. Maniatty wrote:
> I'm probably not quite cool enough to be in on the joke here, but what
> is a dog polisher?

You use it to polish your dog.

Since all good dog polishers connect to computers running unix, you need a
device driver to interface with the dog polisher.

You need to be able to tell the dog polisher what size dog is to be
loaded, how long the dog is to be polished and you will wish to be
notified when the dog is done.

:)

I'm not making this up.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter | This Space For Rent  | ISO8802.5 4ever |



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message