Re: FreeBSD 5.x source update and compilation problem in HP Vectra VE18

2003-12-29 Thread Drew Eckhardt
In message [EMAIL PROTECTED], [EMAIL PROTECTED]
net writes:
Hi,

I installed FreeBSD 5.1 in HP Vectra VE18 PIII 450MHz with 128MB RAM and 
4GB HDD.

Without ECC or even parity memory?

However I'm having problem compiling sources. Whenever I try to make buildworl

d
make stops sometime later saying some variable not found etc. When I check 
that variable from source
it is somehow changed strangely something like: addend changed to adddnd, 
else changed to dlse, INFOPATH
changed to INFNPATH etc. I did cvsup several times, also I used

You're getting uncorrected, undetected single bit errors.

Can somebody help me in this regard? What should I do?

Try different memory, preferably with ECC.

-- 
a href=http://www.poohsticks.org/drew/;Home Page/a
Life is a terminal sexually transmitted disease.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: optionally include file within a Makefile

2003-12-18 Thread Drew Eckhardt
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes:
On 18 Dec 2003 at 19:02, Dan Langille wrote:

 My goal is provide a way to override values in a Makefile with values
 from a local config file.

I'm getting further.  What's the proper way to do an include?

The commands associated with a Make command are passed to the shell.

You need to do your conditional within the make environment, outside
of a rule

.if exists foo
.include foo
.endif

all:
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: file size different from ls to du

2003-07-29 Thread Drew Eckhardt
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes:
(17:13) bgd@(bgd)[~/temp] ls -alsh my_file
19120 -rw-r--r--  1 root  bgd  763M Jul 29 16:56 my_file
(17:13) bgd@(bgd)[~/temp] du -sh my_file
 19Mmy_file

 So the 'ls -alsh' shows a file in size of 763M, but 19M of sectors are
really 'occupied'. Can someone explain, please?

unix files can be sparse.

-- 
a href=http://www.poohsticks.org/drew/;Home Page/a
For those who do, no explanation is necessary.  
For those who don't, no explanation is possible.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: kqueue alternative?

2003-06-15 Thread Drew Eckhardt
In message [EMAIL PROTECTED], [EMAIL PROTECTED]
ux.org writes:
I would say, use select(2).
Is there a reason this wouldn't work?

fd_set size...

-- 
a href=http://www.poohsticks.org/drew/;Home Page/a
For those who do, no explanation is necessary.  
For those who don't, no explanation is possible.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Unix Philosophers Please!

2001-10-31 Thread Drew Eckhardt

In message [EMAIL PROTECTED], Joh
[EMAIL PROTECTED] writes:
What question are you _really_ trying to ask?

What is the sound of one hand clapping?


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



Re: cant port

2001-10-10 Thread Drew Eckhardt

In message 002101c151ad$664255e0$[EMAIL PROTECTED], [EMAIL PROTECTED]
z writes:
hi,
when i am trying to port some program from ports directory (4.3stable) it
never connects to a ftp. Problem might be a firewall, there are so few ports
allowed, but 21 is. Anyone has the same experience?

Of course, establishing an active data connection also means having the
server connect to an ephemeral port on your machine which is not allowed.

make FETCH_BEFORE_ARGS=-p

will give you passive ftp instead.


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



Re: Driver structures alignment

2001-09-15 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes:
On Sat, Sep 15, 2001 at 12:13:58PM -0600, Warner Losh wrote:
 unfortunately, there are many device structures that are passed around 
 via DMA and hte like that don't let you do this...

How come?  The struct represents some [semi-]physical organization?

Other hardware uses the data directly (say scatter/gathre lists for a SCSI 
host adapter or ethernet board) and you can't (or don't want to) change 
the  firmware on the device.


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



Re: ide striping

2001-09-14 Thread Drew Eckhardt

In message [EMAIL PROTECTED], dphoenix@braven
et.com writes:

Does it make sense at all to stripe primary slave,
secondary master and slave together?
I would imagine it is a waste of time , just looking for thoughts
on this vs just a single primary master IDE.

On a normal system, random access time will have a much bigger effect on 
performance than raw throughput.

Although you can transfer 800K sequentially to or from the outer cylinders
on a modern drive in 20ms, it's going to take just as long to transfer a 
single 4K block from an arbitrary disk location because of seek time 
and rotational latency.

So, you'd be better off running a file system on each spindle and spreading
your data out accross those file systems than striping for one big file
system.


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



Re: Some questions about kernel programming

2001-07-13 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED] w
rites:
  ch = fubyte(uaddr);

And one more question, does this mean that I can't use things x = *uaddr
and *uaddr = x for userspace, but always have to use fubyte() and subyte () ?

Right.

If so, what is the reason it was done like that ?

Architectural constraints on some platforms (say you can address just 64K 
at a time.  Obviously, the kernel's 64K and user's 64K can't be accessed 
using normal pointers).



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



Re: Network performance tuning.

2001-07-12 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED]
ane.com writes:
This is fairly easy to do for the transmit side of things and would
yield an immediate improvement in available mbuf space.  For the receive
side of things we can't really do anything with existing connections
(because we've already advertised that the space is available to the
remote end), 

You can't change the RFC 1323 window scale.

You can reduce the window size with each ACK, although this is frowned
upon.

To quote RFC 791, 

  The mechanisms provided allow a TCP to advertise a large window and to
  subsequently advertise a much smaller window without having accepted  
  that much data.  This, so called shrinking the window, is strongly
  discouraged.  The robustness principle dictates that TCPs will not
  shrink the window themselves, but will be prepared for such behavior
  on the part of other TCPs.

Given a choice between failing new connections because insufficient 
buffer space is available and a slow down (both from the decreased
window size and packets dropped by the sender as it's adjusting), the 
later is probably preferable.

Of course, avoiding this by reducing the buffer size of new connections
before you run out is a better idea.

-- 
a href=http://www.poohsticks.org/drew/;Home Page/a
For those who do, no explanation is necessary.  
For those who don't, no explanation is possible.

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



Re: TCP Window Size

2001-07-10 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes:
I'd personally suggest just tuning net.inet.tcp.*space to 64k at most.

1.  Depends on your application.  To avoid TCP window size related slowdowns,
it needs to be at least as large as the bandwidth delay product (multiply
bandwidth by RTT).

2.  net.inet.tcp.*space affects the _defaults_.  Changing them means that
you'll use huge amounts of memory even in places where it doesn't matter
(like ftp control connections).

Instead, use setsockopt with SO_SNDBUF and SO_RCVBUF where appropriate.

-- 
a href=http://www.poohsticks.org/drew/;Home Page/a
For those who do, no explanation is necessary.  
For those who don't, no explanation is possible.

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



Re: processes private data

2001-06-28 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes:
Hi folks,

I have a char driver that must be opened by more than one process. The minor
index is not sufficient for this. Is there any process private data (void *)
in the devfs structure (or the opposite) I could point to with the minor index
of my device?

No.

You want to split your minor number into separate unit and instance parts,
and allow each instance to be only opened once (return EBUSY).  A quick fix
is to continue selecting the softc structure exclusively based on unit
number and to hang the necessary per instance data off that.

-- 
a href=http://www.poohsticks.org/drew/;Home Page/a
For those who do, no explanation is necessary.  
For those who don't, no explanation is possible.

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



Re: allocating user space memory from kernel mode

2001-06-28 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED] w
rites:
Hello,

is it possible to allocate and then maybe free memory in user space
from kernel mode, if I have struct proc of the process that memory should
belong to ? 

Yes.

What is the easiest and safest method of doing this ?

Probably vm_mmap with the MAP_ANON flag and without MAP_FIXED.

I have seen some example that uses obreak(), but that seems very tricky
and suspicious ... I don't really understand what obreak() really does
and how to use it ...

I wouldn't want to confuse the user land memory allocators by changing 
heap size.

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



Re: Query: How to tell if Microsoft is using BSD TCP/IP code?

2001-06-16 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes:
Doesn't any one remember Netiquette these days and trim what they are
replying to??

No.  Every month is September.


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



Re: BSDI and Marketing 101

2001-04-26 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED]
 writes:

I saw BSDIs retail product of FreeBSD in a local bookstore the other day, 
and it became sadly clear why LINUX, although highly inferior, is so much 
more widely used. 

Linux was much more widely used because the Jolitzes felt their i86 unix
port was a research system which didn't need to run on arbitrary hardware
or do what people wanted while Linus was initially working on a Minix clone
that would run on his hardware and maintained that practical attitude 
throughout the project.  

Linux also provided substantially better interactive performance under load,
which was the normal operating state for starving students.  Who in turn
wrote drivers.

Finally, Linux was not endangered by the ATT lawsuit.

Combine these factors, and Linux was more rapidly accepted by starving 
hackers, enough of whom contributed drivers for their hardware rather
than buying something which would work.

The larger hacker community rubbed off on more hobbiests than
the smaller in BSD.  More hobbiests could actually run linux on
their systems because of both hardware support and Wintel coexistance
(things like non-destructive repartitioning, the unix semantics on 
msdos file systems, etc. really helped).  

IOW, Linux was useful to more people sooner.  Even if BSD can match 
Linux's growth rate, that head start means BSD won't catch up in numbers.

Of course, this is irrelevant.  I run BSD on my black (actually,
they're purple) boxes and servers.  I can get jobs doing BSD 
professionally.  If people want to use Linux where BSD works better,
that's their perogative as long as I don't have to hold their hand
or clean up after them.

What they dont seem to realize is that people who know its worth more than 
linux also know they dont have to pay $129. for free software with fancy 
packaging and paid support.

Joe Average (where the numbers come from and perhaps venture capital) is 
going to go with Linux because of name recognition, it works well enough
(which is even better than BSD) for his purposes (Installing some Linux
binaries on BSD requires finding the corresponding Linux libraries, which
is easier said than done.  Installing them on Linux just works.  Linux also
has more complete driver support.  It can coexist easier with Wintel.).

Personally, I'm now running BSD exclusively because it was more flood 
resistant than Linux (my Linux mail server  DNS machine did not survive
the catastrophic water heater failure, while the robust BSD box was more
water tight).

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



Re: stack/memory usage in kernel related question

2001-04-04 Thread Drew Eckhardt

On Wed, 04 Apr 2001 14:12:00 EDT, Amy Fong [EMAIL PROTECTED] wrote:
Query: I've noticed that if I use up too much stack space, the freebsd
kernel (4.2) seems to crash very easily. 

Single page sized kernel stacks aren't uncommon (I don't recall what 
FreeBSD uses, but have found the "it's small, don't allocate arrays there"
strategy to work well).

Specially, if I create an
array of size N within a function, 

Don't put arrays on the stack.  Use kernel malloc instead.


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



Re: Writing to a file in the kernel

2001-03-30 Thread Drew Eckhardt

In message 002d01c0b924$a07d2090$8d7d1f26@dhgfhcpps5nhe1, [EMAIL PROTECTED] w
rites:
The problem is that printf's scroll off the screen. How can I write to a
file?

syslogd(8)/syslog.conf(5).

Also note that by default, on must unices the stock /etc/syslog.conf sends 
kernel messages to /var/log/messages (along with everything else).

YMMV.

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



Re: Question regarding the array of size 0.

2001-03-30 Thread Drew Eckhardt

In message Pine.3.89.10103300924.A22782-010@umbar, [EMAIL PROTECTED]
r.org writes:


which all begs the question... what is the point of an array of size 
zero? 

To allow you to do variable length arrays at the end of structures in a 
portable (C99) or semi-portable (gcc) way


struct records {
unsigned flags;
struct foo[0] data;
};

without jumping through casting hoops.

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



Re: if_fxp - the real point

2001-03-30 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED]
m writes:
And lets face it. If MS had a good product, they would have a much larger 
market share and linux would be a non-issue. MS just makes shitty stuff. 
Its not about "open source". 

Directly, it isn't.

Indirectly, it is.

its about how well it works. 

Although that comes from the software being open source.  If it's open 
source and broken enough to affect me or my employer, I can and will fix 
it, and send patches back to the maintainers.  If it's not, the higher the 
hurdles are the more likely I/we will spend time finding a workarround or 
switching products instead.

Regardless of how good your test team and tools are, there are going to
cases you don't test for, and bugs are going to escape into the field.  With
more competant people in the field that have source you're more likely to 
have the bug manifest in a situation where someone can and will do something
about it.  Open source has the potential to make software more stable than
its closed counterparts, and often does in practice.

By virtue of having more people able to make changes, open source 
also increases your chances of someone being able to justify
the expense (time, opportunity cost from not applying talent elsewhere, 
money, etc) to add a feature.

important, open specs are a competitive advantage.  Over time, they are
likely to win if all else is equal... and in the long run, all else *is*
equal.


Open specs are a competitive disadvantage, because all players are equal. 

It depends entirely on the circumstances.  With small niche markets, you're
much more likely to run into situations where open specs can make a huge 
difference in the number of sales you make.  Look at what happened to 
the PC multiport serial board market.  OTOH, with millions of sales for 
Wintel PCs, sales increases in the thousands of units aren't going to 
make a difference in your bottom line.  

If you're selling black boxes, it may not matter.  Or your customers may
find it reasuring that if you go belly up or discontinue the product they
can still buy support from some one else.

-- 
a href="http://www.poohsticks.org/drew/"Home Page/a
For those who do, no explanation is necessary.  
For those who don't, no explanation is possible.

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



Re: header files for sockets

2001-03-28 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED]
m writes:
the header files they tell you to include are no longer correct. 

The header files are pretty much standard.

So 
what I would like to know is the header files I will need to include to work 
with sockets. If that is not specific enough, here is a brief summary of the 
system calls i will need to use:

Most if not all of the relevant system calls are prototyped in 
sys/socket.h.  For reasons that made since when cave men wrote code on 
stone tablets, sys/* usually don't include sys/types.h, so putting that 
first would be a good idea.

Of course, for all properly documented library functions the man pages
give the header files, and you could always type 

man command

For example

drew@revolt% man socketpair
NAME
 socketpair - create a pair of connected sockets

LIBRARY
 Standard C Library (libc, -lc)

SYNOPSIS
 #include sys/types.h
 #include sys/socket.h

... etc.

-- 
a href="http://www.poohsticks.org/drew/"Home Page/a
For those who do, no explanation is necessary.  
For those who don't, no explanation is possible.

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



Re: Good server motherboard?

2001-03-27 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED]
m writes:
Will the machine boot off of the second drive if the first one fails?

It depends on how you define "fail".  With a hardware failure or no 0x55 0xaa 
in the boot block, many BIOSes will fail over.

At least one company has hacked their BIOS to always boot the next drive 
after an abnormal warm reboot.  Combined with a hardware watchdog, this 
will even catch a bad boot loader or kernel on one drive that's in an
infinite loop.

-- 
a href="http://www.poohsticks.org/drew/"Home Page/a
For those who do, no explanation is necessary.  
For those who don't, no explanation is possible.

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



Re: SCSI-over-* hacks

2001-03-20 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes:
   - the Linux SCSI generic device (/dev/sg*)?

We already have a far superior mechanism (/dev/pass*)

FWIW,

The Linux /dev/sg was implemented as a simple way to send SCSI commands to 
media changer robots in an MO drive library for a medical imaging application,
which found its way into the standard kernel becuase Linux is distributed under
the GPL.

-- 
a href="http://www.poohsticks.org/drew/"Home Page/a
For those who do, no explanation is necessary.  
For those who don't, no explanation is possible.

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



Re: atexit

2001-03-09 Thread Drew Eckhardt

In message [EMAIL PROTECTED], mjl@SD
SC.EDU writes:
I take it that the cleanup function won't be called if the program dumps
core, 

Right, unless you dump core by forking a child process and doing it in that
context.

or if it is terminated with a kill(1) 

The function can never be called when some one does a kill -9, although 
you're free to catch other signals and shutdown gracefully.  

Terminating with a call to _exit() will also not invoke your function.

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



Re: fixing flex definitions?

2001-03-05 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes
:
Would this be an ok fix?  I'm worried about the YY_PROTO() messing
things up anyone know what the point of doing it this way is?

Compatability with pre-ANSI 'C' compilers, just like __P from
/usr/include/sys/cdefs.h.


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



Re: [hackers] Re: Setting memory allocators for library functions.

2001-02-27 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes:
In most cases it is impossible to declare the data read-only because
it originally had to be read-write and you can't change its attributes
later. 

mprotect(2).


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



Re: Is mkdir guaranteed to be 'atomic' ??

2001-02-26 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes
:
is mkdir(3) guaranteed to be atomic?  

Yes.

Are there filesystem type cases where this might not be the case 
(NFS being my main concern )

No.


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



Re: gdb and debugging Linux binaries

2001-02-23 Thread Drew Eckhardt

You may be able to force gdb to pick up the right files using the 
add-symbol-file 
command.

Or the 
sharedlibrary
command.

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



Re: postfix: No buffer space available

2001-02-20 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes:
You might want to try setting
 net.inet.tcp.sendspace
 net.inet.tcp.recvspace
to larger values. I have these in my /etc/sysctl.conf.

These control the default socket buffer size.  Assuming postfix 
is not setting the appropriate socket options, when they are increased
space will run out with even fewer connections.  If they are decreased 
such that they are less than the bandwidth delay product, you will have 
TCP/IP performance problems.

The original poster needs to play with some of the kern.ipc values 
instead, most notably kern.ipc.maxsockbuf.


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



Re: character device driver

2001-02-18 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED] writ
es:
Hi,

I'm writing a character device driver in which each minor device can be
opened more than once.  When a device is opened is there a way to associate
some private data for each opened instance ?

As other people have noted, not in the general case.

The solution I've used is to split the device minor number into a physical
unit and open instance part.  You keep the existing per-unit structure, and
add per-instance data including a busy flag which causes opens to return
EBUSY.  In your user land application, you iterate over the devices in 
round-robin fashion as long as you get back EBUSY as you would for pty 
masters.

-- 
a href="http://www.poohsticks.org/drew/"Home Page/a
For those who do, no explanation is necessary.  
For those who don't, no explanation is possible.


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



Re: Kernel editing tools.

2001-02-07 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes:
Hey everyone,

Sorry if you have heard this before, or if it is annoying. I just can't
seem to find any information on this.

I have been poking around my kernel for quite some time now, and I have
been doing it with various text editors and programs of that nature. It
suddenly occured to me that there might be a better way to go about
this. So I ask you, are there any programs that make reading and editing
the kernel sources any easier? 

Sure - vi.  Among other things, the movement keys are on your touch typing 
homerow, it plays nice with ctags(1), /^function_name works great, and the 
regex based search and replace is real useful.

Surely you aren't all hacking away on vi or the *other* editor.

Reasonable arguments can be made for emacs too.

-- 
a href="http://www.poohsticks.org/drew/"Home Page/a
For those who do, no explanation is necessary.  
For those who don't, no explanation is possible.


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



Re: why isn't /usr/include/sys/syscall.h generated by makesyscalls?

2001-02-05 Thread Drew Eckhardt

In message [EMAIL PROTECTED], Jochen.Kaiser@rr
ze.uni-erlangen.de writes:
hi ,

i am trying to play with some statistics on ip protocols. I'd like
to implement a syscall for some funcions and I wonder why 

sh sr/src/sys/kern/makesyscalls.sh syscalls.master 

updates files in /usr/src/sys/kern/ but not the ones in 
/usr/include/sys/

Because the kernel source tree you're playing with may be inappropriate
for the machine you're building your kernel on.  For example, my current
employer sells black (metaphorically - in reality, they're more of a 
dark blue or purple) boxes which run older versions of FreeBSD than
developers have on their desktop.
 
Any help, including stuff I should read is very appreciated.

make install under /usr/src/sys/include will put the headers in 
the right place.

make followed by make install under /usr/src/lib/libc will get
you a library with the trivial wrapper functions that make the 
actual system calls.

-- 
a href="http://www.poohsticks.org/drew/"Home Page/a
For those who do, no explanation is necessary.  
For those who don't, no explanation is possible.


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



Re: strace

2001-02-02 Thread Drew Eckhardt

In message [EMAIL PROTECTED], m
[EMAIL PROTECTED] writes:
Is there strace for FreeBSD?

There's truss(1) and ktrace(1).

-- 
a href="http://www.poohsticks.org/drew/"Home Page/a
For those who do, no explanation is necessary.  
For those who don't, no explanation is possible.


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



Re: EBCDIC - ASCII

2001-01-29 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED] write
s:

Does anybody know of an EBCDIC to ASCII converter? I thought that at one
time FreeBSD had one of these.

This is a standard dd(1) feature.  More specifically, you want to use the
conv=ascii option.


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



Suboptimal mmap of devices on i86

2001-01-29 Thread Drew Eckhardt

On i86 boxes with 4M page capabilities, we want contiguous chunks
of physical address space for mmaped devices to use those larger pages 
when possible.

In practice, this doesn't happen in applications linked with shared
libraries when mmap() is used in the usual way with 0 as the address 
argument and no MAP_FIXED flag.

mmap() passes vm_mmap() a starting address after the heap.  vm_mmap() 
adjusts this with pmap_addr_hint(), and the result propogates down to 
vm_map_findspace().  When there's insufficient free space to map the 
object at the optimally aligned address because a shared library
is already there, vm_map_findspace() returns the first fit without
adjusting the starting address.

I tweaked my kernel as follows to get pmap_object_init_pt() functioning
as designed.  

--- old Mon Jan 29 16:03:40 2001
+++ vm/vm_map.c Fri Jan 26 18:47:24 2001
@@ -169,6 +169,8 @@
 static void vm_map_copy_entry __P((vm_map_t, vm_map_t, vm_map_entry_t,
vm_map_entry_t));
 static void vm_map_split __P((vm_map_entry_t));
+static int vm_map_findspace_for_object __P((vm_map_t, vm_object_t, vm_offset_t,
+   vm_size_t, vm_offset_t *));
 
 void
 vm_map_startup()
@@ -775,10 +777,20 @@
 /*
  * Find sufficient space for `length' bytes in the given map, starting at
  * `start'.  The map must be locked.  Returns 0 on success, 1 on no space.
+ * 
+ * This differs from the stock vm_map_findspace() in that we have an 
+ * additional parameter (object) which is used to get hints from the
+ * pmap layer which may result in stricter (coarser) alignment.
+ *
+ * FIXME: This should probably replace vm_map_findspace entirely.
+ * We may also want to revert to the historic behavior on failure, in the 
+ * rare event that we have space for the requested region but not at the
+ * optimal alignment suggested by pmap_addr_hint().
  */
-int
-vm_map_findspace(map, start, length, addr)
+static int
+vm_map_findspace_for_object(map, object, start, length, addr)
vm_map_t map;
+   vm_object_t object;
vm_offset_t start;
vm_size_t length;
vm_offset_t *addr;
@@ -811,6 +823,7 @@
 * gap between existing regions, or after the very last region.
 */
for (;; start = (entry = next)-end) {
+   start = pmap_addr_hint(object, start, length);
/*
 * Find the end of the proposed new region.  Be sure we didn't
 * go beyond the end of the map, or wrap around the address;
@@ -837,6 +850,21 @@
 }
 
 /*
+ * Find sufficient space for `length' bytes in the given map, starting at
+ * `start'.  The map must be locked.  Returns 0 on success, 1 on no space.
+ */
+int
+vm_map_findspace(map, start, length, addr)
+   vm_map_t map;
+   vm_offset_t start;
+   vm_size_t length;
+   vm_offset_t *addr;
+{
+   return (vm_map_findspace_for_object (map, NULL, start, length, 
+   addr));
+}
+
+/*
  * vm_map_find finds an unallocated region in the target address
  * map with the given length.  The search is defined to be
  * first-fit from the specified address; the region found is
@@ -859,7 +887,8 @@
 
vm_map_lock(map);
if (find_space) {
-   if (vm_map_findspace(map, start, length, addr)) {
+   if (vm_map_findspace_for_object(map, object, start, length, 
+   addr)) {
vm_map_unlock(map);
if (map == kmem_map || map == mb_map)
splx(s);


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



Re: NEWBUS: multiple calls needed?

2001-01-26 Thread Drew Eckhardt

In message [EMAIL PROTECTED], rh@m
atriplex.com writes:
I think I will just go ahead with allocating three separate resources
for them, but I would be very interested in other opinions.

The different regions on a device often have different functionality which 
may allow/call for different memory access characteristics.  For instance, 
you probably want attempts to write to onboard ROM to fault.  You might mark 
to allow prefetch on large on-device buffers where reads have no side effects.

Beyond that, if a specification does not prohibit a behavior eventually
you'll run into a system that implements it because it seems to make 
sense or is just convienant.

For example, if I thought about accomodating a systems where virtual and 
physical addresses matched (the Linux kernel used to do this), I might pad 
everything to page boundaries and skip a page between entries to make it 
easier to catch overruns.


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



Re: stray irq 7

2001-01-18 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED]
m writes:

I know we've discussed this before. But I cant believe its a "hardware 
problem".

Standard PIC behavior is to assert IRQ7 when an IRQ line is deasserted before 
it can be properly latched in.

and if you've identified it why is there no simple workaround after all this 
time (or is there)?

You can replace the device not keeping its interrupt line active long 
enough, or ignore the spurious int7 messages.


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



Re: Collecting waiting statistics (simulation question)

2000-12-28 Thread Drew Eckhardt

At 09:55 27/11/19 -0700, Jeff Rhyason wrote:
Is there a way that I can log a large amount of statistics
regarding kernel memory allocator activity and make that
accessible to a user process?  (Something like Solaris'
crash(1m) and kmalog)

The quick solution is to config -g your kernel, and extract statistics
via gdb

gdb -x extract-reset-script -k -wcore unstripped-kernel /dev/mem

where extract-reset-script prints the current values, resets, and
then exits.

Otherwise, write a character device driver and matching user land 
facility to extract the information you want.


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



Re: FreeBSD vs Linux, Solaris, and NT

2000-12-22 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes:
Exactly the same in Europe, only the sharing parts are new for me.
The difference seems to be:
The problem is that in the US, it is legal to override this with the
licensing conditions. In Europe this right is inalienable.

Some courts feel that once you've paid for a piece of software, the 
contract has been consumated, and the other party is not allowed to 
make any changes to that contract. For example, they can't tell you 
that once you open the pack containing the floppy diskettes, you agree to 
not reverse engineer the software and if you don't like it you can have
your money back.  Those terms weren't present when the contract was 
entered into, so they're not valid.

Of course, anyone can sue anyone for any reason; and it's often less 
expensive to settle out of court even if you have a legally valid 
position.


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



Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT)

2000-12-21 Thread Drew Eckhardt

In message [EMAIL PROTECTED], admin@bsdfan
.cncdsl.com writes:
Here's the thing about open software that still concerns me. My
background is with the major software development tools companies, so
that is my point of reference. It is great that code is available and
fixes are made and pushed out, but who is doing real testing of these
fixes.  Sure the obvious problem is fixed, but what other problems has
it uncovered, what side effect has it created, and how about
compatibility with other software or drivers in this case.

With commercial software (well at least the places I worked) nothing
could go out the door without a complete QA cycle performed on it.

In a past life, I did half the design and implementation of the
software tracking calls and letting the billing software know 
about them on a CDMA cellular base station.

For hardware, we used machines from the biggest workstation vendor
with a three letter name, running the latest production release of 
their Unix.

Before booting the putz from our team who'd crippled our software
with threads and excised the damage he'd done, we regularly dumped the 
machines out to the ROM monitor.

I know people who work in several operating systems groups at that
company, know a bit about their quality control process, and know that
it was insufficient.

I've yet to encounter a bug of that severity in any released version 
of free software (about the worst which wasn't hardware related is
the FreeBSD Tulip driver not working correctly in full-duplex 
100baseT mode).

So who is testing these fixes in open source world?  

Cygnus is/was doing automated regression testing on GCC.

Just seeing if
the problem at hand is gone isn't real testing, even claiming
thousands of people are now using it isn't enough.  

In theory, a standard suite of white and black box tests should
be superior.

Given inumerable bad experiences with Adobe, IBM, HP, Microsoft, Sun
and other smaller companies, in practice it doesn't seem to work any 
better than the million-monkeys approach.

QA is unglamorous work, but needs to be done.

Does this mean you're volunteering?



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



Re: FreeBSD vs Linux, Solaris, and NT

2000-12-21 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED]
m writes:
Yes but most commercial uses take advantage of the binary distribution 
capability of the BSD license AFTER they've poured their corporate dollars 
into enhancements. With linux you have to give your work away, making it 
much less useful.

To be pedantic, you only need to provide source for works derived 
from GPL'd software which in this case means the kernel propper. User 
land applications and device drivers may be shipped in binary-only 
form because they are separate works, even when distributed in 
aggregation with GPL'd software.



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



Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)

2000-12-18 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes:
  /* Case 1 */   /* Case 2 */
  if (data) vs.  free(data)
  free(data);

I don't see that Case 1 obfuscates anything.  In some cases I find it
clearer:  Case 1 implies that maybe no memory was allocated.  Case 2
seems to imply that memory was indeed allocated.

When functions fit on one screen (where "one screen" is platform
dependant, but probably 80 columns wide (you may want hard copy 
which doesn't wrap) and somewhat less than 60 lines long (given
19" monitors as a defacto standard and the font sizes required
to accomodate aging eyes that have stared at computer screens 
for far too long)), you can see variable definitions and their use
at the same time, if and else clauses at the same time, the end of 
for loops along with what happens to variables just after that, etc.
Such functions can be groked in less time than those suffering 
from sprawl.

Anything which stretches functions out like this 

if (data) {
free(data);
}

rather than this

free(data);

contributes to sprawl, and in marginal cases may be the proverbial
straw which breaks the camel's back.

if (data) free (data);

doesn't pose that problem, although it is inconsistant with most 
coding standards.



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



Re: Text mode video operations

2000-12-18 Thread Drew Eckhardt

In message [EMAIL PROTECTED], bsd_appliance@bemail.
org writes:
I specifically need to know, if possible, how to display hardware-
rendered character- and software-rendered pixel-based images on the
same display at the same time.

This is not possible with straight VGA.

If the graphics aren't too big, you can work arround this hardware
limitation by implementing your graphics as a user defined font.

You may also be able to use the bitblt hardware present on "accelerated"
video boards.



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



Re: syscall assembly

2000-12-13 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes:
In message [EMAIL PROTECTED] Marc Tar
dif writes:
: So why is %esp displaced by 16 bytes when only 8 bytes
: are necessary (4 for $0 and 4 for $.LC0)? And couldn't
: the compiler use a single instruction such as
: subl $16,%esp or addl $-16,%esp? Are two instructions
: used for pipelining purposes, where subl is synchro-
: nised with the first pushl and addl with the second
: pushl?

gcc tries to align stack to 16 byte boundaries as a speed
optiminzation.  Why it doesn't do this in one instruction is beyond
me.

Kocking 16 bytes off the stack pointer won't put it any closer to a 
16 byte boundary.  

 
-- 
a href="http://www.poohsticks.org/drew/"Home Page/a
For those who do, no explanation is necessary.  
For those who don't, no explanation is possible.


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



Re: syscall assembly

2000-12-13 Thread Drew Eckhardt

In message [EMAIL PROTECTED], intmktg@
CAM.ORG writes:
Perhaps, but no matter the degree of optimisation, the
16 byte of space is performed in two instructions. This
leads me to believe is it most likely a pipelining issue
for the following pushl instructions. As for subl'ing and
addl'ing 8 bytes instead of 4, as required by each pushl,
that can very well be an aligning issue which would seem
to make more sense for the x86.

pushl puts the operand on the stack and then decrements %esp
by an appropriate quantity.

Nothing needs to be done to the stack before it.

My best guess (if it isn't a bug) would be that it's there to keep the stack 
on a 32 byte (IIRC, this sounds like cache line size for the newer 
Intel chips) boundary when the program gets to open (4 for saved %ebp, 4 
for the char * arg, 4 for the int arg, and 4 for the %eip call pushes 
requires 16 bytes more to preserve a 32 byte alignment) so that in a 
"normal" function without a lot of locals all of the locals are on the 
same cache line.

Two instructions instead of 1 would help to facilitate alignment of the 
return address (I think 16 bytes is a good alignment for a jmp, and 
I can't see why a ret wouldn't the same), and a subl + addl combination
would prevent interferance by a stupid peephole optimizer looking to 
combine addls with the same destination register.

-- 
a href="http://www.poohsticks.org/drew/"Home Page/a
For those who do, no explanation is necessary.  
For those who don't, no explanation is possible.


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



Re: syscall assembly

2000-12-13 Thread Drew Eckhardt

drew writes:
My best guess (if it isn't a bug) would be that it's there to keep the stack 
on a 32 byte (IIRC, this sounds like cache line size for the newer 
Intel chips) 

This discussion piqued my curiosity, so I popped up the Pentium III
optomization manual.  To quote it:

On Pentium II and Pentium III processors, a misaligned access that
crosses a cache line boundary does incure a penalty.  A Data Cache
Unit (DCU) split is a memory access that crosses a 32-byte line boundary.
Unaligned accesses may cause a DCU split and stall Pentium II and Pentium
III processors.  For best performance, make sure that in data structures
and arrays greater than 32 bytes, the structure or array elements
are 32-byte-aligned and that access patterns to data structure
and array elements do not break the alignment rules.

IOW, the stack pointer adjustment is there so that doubles 
(and 80-bit floats, if GCC supports those.  Does it do a long double
for Intel targets?) in the called function don't cross a 32 byte data 
cache line boundary.

Two instructions instead of 1 would help to facilitate alignment of the 
return address (I think 16 bytes is a good alignment for a jmp, and 
I can't see why a ret wouldn't the same)

PII/PIII processors prefetch on 16 byte boundaries, so having
the return address on such a boundary may cut the number of prefetches
and (marginally) improve performance.

-- 
a href="http://www.poohsticks.org/drew/"Home Page/a
For those who do, no explanation is necessary.  
For those who don't, no explanation is possible.


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



Re: sudo [was: Re: your mail]

2000-12-06 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes:
David Talkington wrote:

 sudo definitely helps if it's carefully administered, but it still
 grants root access to a file,

This is wrong -- sudo will grant access with whatever user
privileges you wish to grant, maybe root and maybe some other
user.  It all depends on the way you set it up.

Unlike a potential ACL solution, sudo also logs which privledged
commands were executed when and how, thus letting you know who
within the hierchy broke what and how...


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



Interrupt threads

2000-11-21 Thread Drew Eckhardt

For reasons beyond my control, I'm stuck using FreeBSD in a real time 
system and am violating my timing constraints when too many SCSI commands 
complete in a short time frame and starve one of my userland real time 
processes.

If the interrupt handler wokeup a kernel thread running at a lower 
real-time priority than my application which disabled the interrupt
on the PIC/APIC, ran the handler, and re-enabled the line on the
PIC/APIC my problems should go away.

-CURRENT supposedly uses threads for interrupts.  Is there a more specific
description of what it does archived somewhere?  Assuming familiarity 
with the interrupt code and a cursory but improving understanding of the 
scheduler, how messy would it be to retrofit that code to -stable or 
3.1-stable ?


-- 
a href="http://www.poohsticks.org/drew/"Home Page/a
For those who do, no explanation is necessary.  
For those who don't, no explanation is possible.


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



Re: Panics when using Mylex RAID with SMP under RELENG_4

2000-05-02 Thread Drew Eckhardt

In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes:
I am trying to run a Mylex Acceleraid 1100 in a Dell Poweredge 2450.  

What is a Dell Poweredge 2450, in terms of chipset and processors?

When
running rawio against the mylex partition, the system panics within 2
minutes, always with a trap #29.  I have kernel dumps for four panics, but
kgdb doesn't show any similarities between the panics (other than that they
are all #29).

To add another datapoint:

I just swapped the 350MHz PII in my Super Micro  P6DGS (your generic
440GX dual slot-1 board) for a pair of PIII600Es.  Since then, I have been 
getting panics under both 4.0 and 5.0 current from trap 29 that seem 
correlated to IDE disk I/O load.

The first crash dump I grabbed showed that the faulting address was 
idle_loop + 64, which is at the cli instruction.

Trap 29 could come from processor fault 19 (SIMD), an APIC, or PIC.  Since 
cli isn't a SIMD instruction, I suspect the APICs or PICs but have yet to 
instrument and test this hypothesis.

  tf_eip = -1071757093, tf_cs = 8, tf_eflags = 582, tf_esp = 0,
  tf_ss = -8359936}) at ../../i386/i386/trap.c:586
(kgdb)

What do you get when you feed kgdb 

frame 3
info line * (void *)frame-tf_eip

?

-- 
a href="http://www.poohsticks.org/drew/"Home Page/a
For those who do, no explanation is necessary.  
For those who don't, no explanation is possible.


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



Re: Inetd and wrapping.

1999-06-25 Thread Drew Eckhardt
In article 199906242353.taa06...@smtp4.erols.com you write:

Here's one possibility,  it adds a a wrap/nowrap field that goes beside the
wait/nowait field, so you would have:

ftp stream  tcp nowait  wrap root   /usr/libexec/ftpd   ftpd -l

Breaking backwards compatability is evil.  Do something like this instead -

ftp stream  tcp nowaitwrap root   /usr/libexec/ftpd   ftpd -l



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message