Re: Enhancing cdboot [patch for review]

2008-12-11 Thread Bruce M. Simpson
This sounds and looks cool, diff looks OK (haven't applied), Luigi's 
comments seem well thought out and expressed.


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


Re: Anyone interested in HDLC support for pppd ?

2008-06-03 Thread Bruce M. Simpson

[EMAIL PROTECTED] wrote:

Hello;

I started playing a bit with net/pppd23 and I noticed there are some patches for 
FreeBSD-3.0 that were never committed (NetBSD certainly has them). Our pppd(8) is derived 
from the samba pppd port and should have them if we want to continue updating 
it.
  


Ed Schouten is currently rewriting the tty code. It sounds like line 
disciplines are about to go away, so pppd23 will most likely stop 
working at that point.


There's a Netgraph node ng_cisco which claims to support HDLC. Perhaps 
tweaking MPD to work with it is a better use of effort.

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


Re: [PATCH] Fancy rc startup style RFC

2006-04-19 Thread Bruce M Simpson
On Wed, Apr 19, 2006 at 10:46:09AM -0400, Coleman Kane wrote:
 My point is that we should let our purist values get in the way of others'
 enhanced experience using the system.

My view is: We take the patch, as long as it doesn't interfere with
the internal machinations of rc too much.

There are good aesthetic and functional arguments on either side.
Given the excellent work on rc to date, we have clean abstractions
in rc itself, so fitting colour-aesthetics in does not have a high
maintenance cost.

I agree strongly with the functional arguments however and think that
this stuff shouldn't be turned on by default. I think that it should be
available in the base system for those who wish it.

I feel that this should be both for aesthetic reasons and for promoting
FreeBSD to the ultimate end, that is, to potential users, who may find
it easier to relate to FreeBSD if the console messages are in colour,
no matter how irrational that may seem to some!

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


Re: User mounting take 2

2006-04-15 Thread Bruce M Simpson
On Sat, Apr 15, 2006 at 01:05:45AM -0400, Joe Marcus Clarke wrote:
 Finally, in testing this, I found a problem with smbfs, msdosfs, and
 ntfs relating to the statfs(2) f_flags field.  smbfs always set this to
 0, msdosfs didn't set this at all, and ntfs set this to all flags (not
 just those visible to statfs(2)).  By fixing this, umount(8) works
 properly on relative paths to user mount points for those three file
 systems.

Very very cool. I've seen this behaviour before and it was annoying
because it meant having to sudo to do user SMB mounts in my home
directory.

Thanks muchly for doing this work.

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


Re: Using any network interface whatsoever

2006-04-10 Thread Bruce M Simpson
On Sun, Apr 09, 2006 at 06:48:25PM -0600, M. Warner Losh wrote:
 I though thtis was already supported.  We export bus/slot/function
 information devd, which can be used to configure the device.

If I've read the specs or code incorrectly please do let me know --
my reading here is based on the PCI code as I understand it to be.

As I understand things, the bus/slot/function numbers in pci(9), the
*slot* number isn't guaranteed to have any meaning in geographic reality;
it's purely what the PCI logic thinks the bus topology looks like and
hence what the device numbers are. See BUGS in pci(9).

It won't tell you that a given card is in a given slot with any degree
of certainty or consistency across the range of backplanes available
from multiple vendors -- although people may like to give PICMG a try
as I hear such boards are consistent about such things.

In the old Microsoft-specified $PIR tables there was a column which
allowed you to map the bus/device/function tuple we use to a physical
slot number, but this only ran 1-6. With multiple PCI buses and slot
types, as well as multifunction devices, this information quickly became
unusable and unreliable, although src/tools/tools/pirtool will happily
display this information.

ACPI as you no doubt know does away with the $PIR tables, although many
BIOS still export them to allow legacy DOS programs which use PCI to work.
There is an extension to ACPI which adds geographical slot addressing
to the device tree but I haven't seen any systems which support it.

Regards,
BMS

P.S. I have some notes somewhere about the ACPI geog stuff but can't
remember if I posted them or filed them elsewhere -- check the XORP
mailing lists, I think we bashed this out there around 14 months ago.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Using any network interface whatsoever

2006-04-09 Thread Bruce M Simpson
Mike,

Tell me about it, I know exactly what you mean!

On Sat, Apr 08, 2006 at 06:53:11PM -0400, Mike Meyer wrote:
 My question about labels for ethernet devices wasn't meant to be
 rhetorical. Ethernet device names on Unix are pretty much
 worthless. They tell you basically nothing about which device you've
 got. On FreeBSD, different card types have different names, which is
 better than nothing - but that's about all it's better than. We need
 something akin to labels for ethernet devices. The LAN it's plugged
 into is the equivalent of the data on the disk - but there's no
 equivalent for the label.
 
 What do I want for that? I identify ethernet boards by which slot on
 the back of the system I plug the cable into. Currently, I have to map
 that to board types to and which board is plugged into which slot to
 know which name to use. I want a name that tells me which slot I plug
 a cable in to plug it into that interface.

I investigated this problem when doing research on XORP. The behaviour
you describe is a functional requirement for a router chassis.

What it really comes down to is that one needs a PCI variant which supports
what's known as 'geographical addressing', and for FreeBSD's device / ifnet
framework to support naming cards according to the geographic i.e. physical
address.

If you look at the very bottom of the man page pci(9) you'll see I've
left a footnote about this.

Unfortunately the only systems which tend to implement this feature at
the moment are CompactPCI based chassis systems. Although there is support
for geographical addressing in a recent ACPI spec but as far as I know
it may only really have made its way into blade systems.

Hope this helps.

Regards,
BMS

P.S. If etiquette were taken more seriously then society as a whole might
function better -- I think of it as part of the 'operating system' of
the human spirit!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: copy paste in freebsd

2006-03-24 Thread Bruce M Simpson
On Fri, Mar 24, 2006 at 01:52:20AM -0800, Divya B wrote:
  Here is the problem i am facing with freebsd. 
  1. copy some text from a file or any window
  2. close the file or window
  3. try pasting it in another place.
  Paste is not happening. Is freebsd lagging in this? Or  have I missed 
 something? 

FreeBSD is an operating system; it's not an integrated graphical
environment. It is easy for novice users to be confused about this.

You haven't told us here if you're using the text-based console, the X
windowing system, or any particular combination of X terminal program
and/or window manager, so it's difficult to offer useful advice.

If the former, it could be a FreeBSD issue, i.e. with moused or the
console driver, but you have pointed out that you're using a window,
so I will assume you're using X (this implies it is not a FreeBSD issue).

Traditionally X's clipboard support has been threadbare at best.
Having said that, you may wish to try a clipboard manager program of
some kind if this sequence of events is a problem for you.

I would suggest you try installing KDE or GNOME or a similar environment
and see what works for you as the concept of 'clipboard' is treated very
differently by such environments.

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


Re: newbus questions

2006-03-16 Thread Bruce M Simpson
On Thu, Mar 16, 2006 at 01:59:52PM +0300, Artem 'ZaZooBred' Ignatiev wrote:
 I need some help regarding newbus architecture. I'm trying to write
 driver for budget DVB cards. 

I think Sami Bahra was going to port Video4Linux, so search archives
and check in with him.

I had a DVB card but gave it away 2 weeks ago.

For IP over DVB info, check out Gorry Fairhurst's papers.

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


Re: watching a file for ownership change

2005-05-23 Thread Bruce M Simpson
On Sat, May 21, 2005 at 10:38:30PM -0400, Charles Sprickman wrote:
 I'd like to find a way to watch one of the user's maildirsize files that 
 seems to flip ownerships at least once a day and try to determine what 
 process is changing the ownership.
 How can I do that without dropping a bunch of daemons on a production 
 machine into heavy-debug mode?  OS is 4.8 with all current patches.

You could try watching kevent() on the file for EVFILT_VNODE with NOTE_ATTRIB.
You'd need to write a small C program to do this.

Whilst this won't tell you who did what, it could give you sufficiently
good timestamps from it happening to begin tracking the culprit down further,
perhaps using lsof.

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


Re: Accessing BIOS memory range

2005-05-12 Thread Bruce M Simpson
On Thu, May 12, 2005 at 09:58:10PM +0200, alexander wrote:
 I'm writing a little app in 32 bit x86 (386 minumum) assembly, where I need 
 to access
 some memory in the BIOS range. The real address is 40h:6Ch (virtual = 
 ((0x404) | 0x6C)).

Just use /dev/mem. It will do what you want.

Look at src/tools/tools/pirtool for a simple example.

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


Re: PCI Programming

2005-04-28 Thread Bruce M Simpson
On Thu, Apr 28, 2005 at 07:39:33PM +0200, Cole wrote:
 If anyone has any sample code or anything that I could read to proceed any 
 further, it would be greatly appreciated.

Have a look at the man page in section 9 for pci. You should be able to find
most of what you need there. You should probably also look at one of the
simpler PCI drivers in the kernel tree to see how similar things are done
in FreeBSD land. Though it looks like the idiom you're trying to port may
not be needed (you can just match the IDs in your driver's probe or attach
routine, when the pci bus parent driver calls them through NEWBUS).

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


Re: Problem with: OSPF thru netgraph Gif Tunnels

2005-04-25 Thread Bruce M Simpson
On Sun, Apr 24, 2005 at 10:41:31PM -0700, Chris Bose wrote:
 I?m trying to setup a network between two locations over a WAN and I?m 
 running into a wall when I try to get OSPF to talk over my WAN tunnel.  I?ve 
 realized that I?m not smart enough and need your help.

I haven't looked in depth at the information but it sounds to me as though
the most likely failure mode is that multicast isn't working over the gif
tunnel for whatever reason.

You could try configuring OSPF in NBMA mode over the tunnel, that way OSPF
discovery isn't dependent upon multicasts being forwarded over the tunnel,
but requires you to explicitly specify the OSPF peers at either end.

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


Re: preadv() / pwritev()

2005-04-25 Thread Bruce M Simpson
On Mon, Apr 25, 2005 at 12:10:08PM +0200, Marc Olzheim wrote:
 Are there plans on implementing preadv() and pwritev() ? I kind of miss
 the functionality and I saw NetBSD had it already...

By the looks of pwrite() and writev() it could probably be implemented
fairly easily; it would largely be a matter of rototiling pwrite() to
accept an array of iovecs, as writev() currently does, as pwrite() already
knows how to pass a single uio/iovec on the stack with the desired start
offset. Looking at the man page for pwritev() it only accepts a start
offset, rather than an individual offset for each scatter/gather element.

I don't do enough thread-based programming at the moment to make this worth
my while, though, but I'm happy to look at a patch.

BMS


pgpClgMnMoRjH.pgp
Description: PGP signature


Re: preadv() / pwritev()

2005-04-25 Thread Bruce M Simpson
On Mon, Apr 25, 2005 at 06:50:41PM +0200, Marc Olzheim wrote:
 More like this then...

Yep, something like that! Thanks, though I may not have time to commit
this at the moment. :-(

BMS


pgpzcrqJRUpsG.pgp
Description: PGP signature


Re: A question about hot-pluggable PCI.

2005-04-13 Thread Bruce M Simpson
On Mon, Apr 11, 2005 at 11:21:14AM -0600, M. Warner Losh wrote:
 No we don't.  We use what the BIOS provides, but will lazily allocate
 the BARs as necessary.  We don't open the resource windows on the
 bridges, however.

This 'sorta' works now.

I program a hard-coded window into the PCI bridge behind CardBus. Drivers
attaching to devices behind the bridge are able to get the ranges they need,
with the exception of the ATA controller inside the chassis, which I know
is a special case for PCI.

This of course is a hack which may not work for the !i386 case, as it relies
on the HUB-PCI bridge behaviour of Intel chipsets, which is to pass all
transactions across (according to some of the comments in pci_pci.c).

It turns out interrupt routing is the problem. I don't think it's possible
to route an interrupt across CardBus to a downstream PCI bridge in the same
way as is usually done for PCI-PCI bridges.

When I added the following, I found drivers attaching to devices inside the
chassis were able to allocate interrupts and service them:-

%%%
+if (!strcmp(device_get_name(bus), cardbus))
+intnum = 11; /* Hardcode the IRQ routed to my CardBus bridge */
+else
 intnum = PCIB_ROUTE_INTERRUPT(device_get_parent(bus), pcib, parent_intpin 
+ 1);
%%%

...whereas normally the code was 'routing' IRQ 6 to INTA on the bridge.
I don't see a pcib_route_interrupt method for pccbb, which is the grandparent
of the pcib instance I'm attaching. So I check if the devclass of the immediate
parent is cardbus.

This suggests that the code may have been erroneously routing an interrupt
from 1 level up in the PCI bus hierarchy, which would explain why cbb was
rejecting drivers downstream asking for IRQ 6 (my function interrupt is
IRQ 11, I have no idea what IRQ 6 is, so I'll reject the allocation).

However, it looks as though this doesn't do the right thing just yet, because
drivers panic on detach when calling bus_release_resource() for their IRQ.

 : I had also thought of passing down a 'cold' flag, for pcibX to indicate to
 : pciY that this is a 'cold attach' (the BIOS hasn't been anywhere near the
 : devices behind this bridge -- it is as fresh as after a RST# assert).
 
 I don't think that's a wise idea.

Currently, in pcib_attach(), after the call to pcib_attach_common(), I check
to see if sc-secbus is 0. If it is, I call a new function,
pcib_attach_cold(), which tries to initialize the bridge as if the BIOS
had never touched it.

So far this 'kinda' appears to do the right thing; the onboard OHCI controller
gets its resources OK.

I imagine some of the code from this effort could be cleaned up and pushed
back into the tree to support other forms of PCI hot-plug in future.

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


Re: kernel killing processes when out of swap

2005-04-12 Thread Bruce M Simpson
On Tue, Apr 12, 2005 at 05:24:15AM -0700, ALeine wrote:
 machine. Having a flag to tag processes as vital to prevent them from getting
 killed (or to give them lower next-to-be-killed priority so that all non-vital
 processes get killed first) when you run out of swap would be a useful 
 feature,

P_SYSTEM provides something like this feature, amongst others. It is used by
init(8).  However P_SYSTEM also says that process statistics should not be
maintained, and that the signals that may be dispatched to such processes
are restricted.

It would be more appropriate if such processes use the mlockall(2) call for
the time being.

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


A question about hot-pluggable PCI.

2005-04-11 Thread Bruce M Simpson
Hi,

I have acquired a Mobility Electronics EasiDock 5000. As some of you may
already know, this is a device which allows you to connect regular PCI
cards to your laptop, using a device called a 'Split Bridge'. (*)

Ok. Cool toy, you may be thinking. Indeed.

But I want to make it work with FreeBSD. (+)

I'd love to hear from anyone who has plans to implement hot-plug in
a BSD, because this is the missing piece of the puzzle currently.

It seems that this device is known to work with Linux, with some further
hacking of support which Magma (who acquired Mobility a few years back)
provide on a 'as is' basis.

So I've begun hacking the pci and pcib drivers from RELENG_5_4 to support
this device. So far, I've been able to probe configuration space. I see
all the devices on the PCI bus inside the expansion chassis.

However I cannot get drivers to attach properly, because resources have
not been assigned to the cards. Normally the BIOS would do this. But
because BIOSes do not normally explore beyond the CardBus bridges, none
of the devices have had their I/O, memory, or interrupt registers set
to non-default values; everything is the same as a pristine bus reset,
even when I boot with the bridge card in a CardBus slot.

In order to get this far I've had to add NEWBUS detach methods to both
pci and pcib, as well as some cleanup in pci_pci.c, and some downright
dirty hacks to deal with subordinate bus numbering which rely on the
current behaviour of our CardBus driver.

I'll post diffs if anyone else is interested; but right now it's pretty
trivial stuff.

Cheers,
BMS

[(*) It is so called because unlike a normal PCI-PCI bridge, the bridge is
'split' in two; there is a CardBus card which goes into your laptop,
to which is connected a proprietary high-speed serial bus cable.
At the other end is a PCI chassis which looks much like any other desktop
PC, which has a jack for the proprietary connector out of the back, wired
up to the other half of the 'split bridge'; this sits on a passive PCI
backplane with several ordinary 33Mhz 32-bit-wide PCI slots.]

[(+) Yes, I know, if OpenCores.org had a PCI IEEE 1394 cell which could just
tunnel arbitrary PCI I/O and configuration transactions, we could implement
this thing using $20 cards from a chain store. If only.]


pgpQ9Kdjbhr1U.pgp
Description: PGP signature


Re: A question about hot-pluggable PCI.

2005-04-11 Thread Bruce M Simpson
On Mon, Apr 11, 2005 at 07:25:07AM -0600, Scott Long wrote:
 Asking for 'hotplug support' is pretty generic and non-descriptive.  Are
 you asking for device level hotplug support, where we carefully drain
 transactions out of a device, device driver, and whatever I/O or network
 or whatever layers are above it?  Or are you talking about PCI hotplug
 support?  If so, which de-facto standard?  Compaq?  IBM?  ACPI?
 PCI-SIG?  Something else?

Sorry, I thought my original post was quite clear; in order to support
my hot-pluggable PCI chassis, FreeBSD needs to grow the ability to manage
PCI resources without any firmware support (other than possibly the ability
to route interrupts). Since I sent that mail I looked at the requirements
list for 5-STABLE and realized this is in fact on it.

I think there's a fair chance that any other PCI hotplug standard is going
to need the same changes I need to make my split bridge work.

I looked in src/sys/dev/cardbus/cardbus_cis.c, and Linux's ACPI-based PCI
hotplug driver, and realised that at the lowest level, they are all in fact
pretty much doing the same thing -- that is, setting all bits in a BAR, and
then figuring out the desired aperture size for each BAR, allocating the
appropriate resources using rman, figuring out base addresses, etc.

We currently rely on the BIOS to do this. The bit I've been discussing with
Warner is how to deal with the problem of setting subordinate bus numbers,
though because I can get away without doing that for the 'pcib is an immediate
child of cardbus' case, I haven't done it.

I had also thought of passing down a 'cold' flag, for pcibX to indicate to
pciY that this is a 'cold attach' (the BIOS hasn't been anywhere near the
devices behind this bridge -- it is as fresh as after a RST# assert).

That's enough for me to be getting on with just now, though it would be nice
to have some general architectural advice on where exactly this logic should
go, because it's something cardbus is using to mop up the edge cases where
device resources are not fully described in the CIS.

I am undecided as to whether I should try to separate out my changes to
src/sys/dev/pci/pci_pci.c into a new driver or not.

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


Re: name cache cont.

2005-03-28 Thread Bruce M Simpson
On Mon, Mar 28, 2005 at 05:42:52PM +0400, Igor Shmukler wrote:
 For my purposes the Linux/DragonFly functionality is needed.
 
 Is there a way to know that once a patch that correctly resolves corner cases 
 for 
 vn_fullpath() (including name cache changes) exists it will be committed to 
 the 5.x 
 branch?

Hey, I did some of this work quite some time ago. It is still floating
around in the archives. I'm more than happy for people with more vfs
knowledge than I to pick it up, review it, and commit it, but I don't
have free time to do this right now.

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


Re: relation between PQ_CACHESIZE and PQ_L2_SIZE

2005-03-26 Thread Bruce M Simpson
On Sat, Mar 26, 2005 at 09:44:36AM -0800, Bao Zhao wrote:
 some think it is 4-way set associative,but I think it
 is the page's size-4KB.
 
 If I'm right, How BSD deals with 8KB page size?

Please search this list's archives as there's a thread on this from a
few years back (I was one of the protagonists).

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


Re: poll or select for ppi?

2005-03-14 Thread Bruce M Simpson
On Mon, Mar 14, 2005 at 10:05:34PM -0500, Matt Kory wrote:
 Is it possible to use poll or select to detect a change in the status
 bits of the parallel port?  I tried something like this, and took bits
 5 and 6 of the status register low and nothing seemed to happen.  Is
 what I am trying to do even possible, or I am supposed to take a
 certain bit low to cause a read event?  Any help is appreciated.

Disclaimer: I'm no expert on the parallel port.

The man page for ppi(4) says that all I/O is via ioctl(), which isn't
covered by the select() mechanism.

You'd either have to poll PPIGSTATUS from userland on a timer, or perhaps
hack the driver to use a kevent. Considering there's probably no way to
get a hardware interrupt for the status change directly via ppi(4), you
might need to consider writing a set of custom ppbus microsequences and
a driver for your application.

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


Re: Rawsock bpf mambo jambo?

2005-01-25 Thread Bruce M Simpson
On Tue, Jan 25, 2005 at 10:46:47AM +0100, DJF wrote:
 What's the advantage in using the rawsock bpf combination instead of
 bpf (or raw socket) only?

Raw IP sockets for write take care of the following for you:
1) Computing IP checksums.
2) Inserting IP options.

BPF does neither of those things. For a while BPF was read-only, but it
has been read-write capable for quite some time.

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


Re: OpenBSD's netcat in base or ports?

2005-01-25 Thread Bruce M Simpson
On Tue, Jan 25, 2005 at 01:46:30PM -0500, Coleman Kane wrote:
 This is only my personal opinion. I think the WITH__OVERWITE_BASE
 make options help substantiate it, however.

I've recently updated the tcpdump port to fix a number of issues. If
people could confirm that the OVERWRITE_BASE option still works there,
I should be most grateful.

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


Re: Resuming from a crashdump

2005-01-24 Thread Bruce M Simpson
On Mon, Jan 24, 2005 at 07:37:34PM -0600, Ryan Sommers wrote:
 My little knowledge on this subject aside. I'd love to have full 
 suspend/resume functionality. It'd make my life as a mobile freebsd user 
 much much easier. However, I wouldn't want it at the expense of every 
 kernel. It would need to be something completely modular.

I think what we're also looking at is aborting any pending bus-mastering
transactions. This could probably be done as a part of the newbus
suspend/resume routines for bus and device drivers, but it also means
that the other entry points need to be able to deal with the carpet
being dragged out from under them like this.

In the case of a networking driver, particularly Ethernet, things are
somewhat easier, and the more help you get from the hardware the better;
but some cards like those based around ATM SARS just plain aren't designed
to deal with the carpet being dragged out - they expect to keep rolling
through their descriptor rings, segmenting and transmitting what they see.

If we could take a clean subsystem-by-subsystem approach to marshaling
kernel state to disk, that would be good. What gives me particular pain
here is dealing with things like the filesystem. How does one deal with
open files, etc, with pending I/O?

Just my 2c,
BMS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Wondering about a patch (DELL ERA/RAC)

2005-01-20 Thread Bruce M Simpson
On Wed, Jan 19, 2005 at 03:58:23PM -0800, dpk wrote:
 I just got a test server set up for this. The patch worked fine. I lifted
 a pppd command line from a linux mailing list:
 
 pppd /dev/cuaa4 1382400 crtscts noipdefault noauth lock persist connect 'chat 
 -v  CLIENT CLIENTSERVER \\c'
 
 and I'm able to access the device via the ppp0 interface.
 
 FWIW, I am using FreeBSD 4.10 here. Thanks for updating the patch!

Committed to -CURRENT, MFC pending 1 week. Thanks!

BMS


pgppx57OF7jcb.pgp
Description: PGP signature


Re: Kernel mode programming

2005-01-18 Thread Bruce M Simpson
On Tue, Jan 18, 2005 at 11:45:05AM +0100, - Felix - wrote:
 Doing lot of syscalls interrupts in a soft seems to take quite a long time, 
 and seriously slow performances. As far as you can't reduce the syscall 
 amount, is there any way to run apps in kernel mode, in order to call 
 sysfonctions directly ? Perhaps by re-writing softs in kernel modules ? 

For 95% of applications syscall overhead shouldn't have a major impact on
performance. It's difficult to offer any real advice here because you haven't
said what the application is, or shown any profiling figures.

Maybe you should review your design? Trying to avoid repeating what other
posters have said here.

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


Re: Geode integrated peripherals support?

2005-01-17 Thread Bruce M Simpson
On Sun, Jan 16, 2005 at 03:01:17PM +0100, Milan Obuch wrote:
 ACCESS.bus support (i2c bus compatible) and LPC bus bridge (for expansion).
 The first one is present in OpenBSD. I am currently studying that and FreeBSD 
 kernel sources to try port it, however, any help would be great. No idea on 
 LPC, through...

There's some i2c support in FreeBSD already, whether or not this applies
to the i2c hardware in the Geode I don't know. iic(4) would be a good
place to start.

LPC just looks like ISA for most intents and purposes, and if we didn't
support ISA, we couldn't boot on i386...

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


Re: ASIX AX88172 OS X?

2005-01-10 Thread Bruce M Simpson
On Mon, Jan 10, 2005 at 04:26:18AM -0600, Kris Tilford wrote:
 I assume your FreeBSD driver could be easily ported to OS X, I could 
[snip]

Nope. MacOS X and FreeBSD are completely different in this area. It uses
a driver API known as IOKit. Your best bet is to look for driver support
from the manufacturer.

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


Re: Raw sockets problem?

2005-01-09 Thread Bruce M Simpson
On Sat, Jan 08, 2005 at 11:34:57PM +0100, Ivan Voras wrote:
 I use it in this code:
 
 /* get interface name by index */
...

Please consider using if_nameindex() or if_nametoindex(), which will retrieve
the getifaddrs() list for you and considerably simplify the code fragment
you've provided.

These are specified by RFC 2553 and are used in many places within the XORP
open source router.

Regards,
BMS


pgpnKvYB8cZ9Y.pgp
Description: PGP signature


Re: Wondering about a patch (DELL ERA/RAC)

2005-01-09 Thread Bruce M Simpson
On Sat, Jan 08, 2005 at 07:17:33PM -0800, dpk wrote:
 Will this patch be making its way in to the kernel? The Dells are still
 shipping with cards that have no drivers (this pciconf -v -l is from a
 1750):

Please try the attached patch. You'll need to have these drivers
statically compiled into your kernel (with the patch applied)

device  sio
device  puc

I don't have one of these devices so I'm unable to test.

Hope this helps,
BMS
Index: pucdata.c
===
RCS file: /home/ncvs/src/sys/dev/puc/pucdata.c,v
retrieving revision 1.45
diff -u -p -u -r1.45 pucdata.c
--- pucdata.c   17 May 2004 12:57:30 -  1.45
+++ pucdata.c   10 Jan 2005 05:43:47 -
@@ -1203,5 +1203,14 @@ const struct puc_device_description puc_
},
},
 
+   /* Dell RAC Serial PPP Link */
+   {   Dell RAC Serial PPP Link,
+   {   0x1028, 0x0008, 0,  0   },
+   {   0x, 0x, 0,  0   },
+   {
+   { PUC_PORT_TYPE_COM, 0x14, 0x00, DEFAULT_RCLK * 128 },
+   },
+   },
+
{ 0 }
 };


pgpPjLZRU6Og0.pgp
Description: PGP signature


Re: network trunkin

2005-01-09 Thread Bruce M Simpson
On Sun, Jan 09, 2005 at 02:48:18AM -0800, Matt wrote:
 Does anyone know if FreeBSD supports trunking?  By that I mean spreading 
 network traffic over multiple interfaces to achieve a higher aggregate 
 throughtput.  I've used this with Solaris.  Thanks.

Were you thinking of any particular Ethernet trunking standard? I assume
you're referring to Ethernet.

ng_fec(4) is a Netgraph node which suports Fast EtherChannel, which is
a Cisco-ism. It may not be what you want.

The IEEE standard for Ethernet trunking is 802.3ad Link Aggregation
(aka LACP in Cisco-ese). As far as I know we don't currently support
802.3ad.

You might also wish to investigate ng_one2many(4), which is a bit
more simplistic.

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


Re: UCARP support for FreeBSD

2004-12-08 Thread Bruce M Simpson
On Wed, Dec 08, 2004 at 01:02:09PM -0600, Scott M. Ferris wrote:
 ucarp will compile and run, but will silently fail to send heartbeats
 due to the way libpcap
 opens bpf on FreeBSD.  You can find a patch to libpcap in PR 72814.
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=72814

This is something else which needs a pcap/tcpdump update. Currently there
is no way to specify this behaviour at runtime.

Hopefully this should be resolved at the next import.

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


Re: about a usb adsl modem driver

2004-12-03 Thread Bruce M Simpson
On Fri, Dec 03, 2004 at 09:25:56PM +0100, Jose M Rodriguez wrote:
 But noted strong differences between atm boards and adsl modems.
 
 - atm boards are hardware assisted.  usb adsl modems are bare assisted.
 - atm boards support better signaling, multiple channels, ... usb adsl 
 modems just one PVC with uni signaling.

Not really. See below.

 So I realize that try to get a NATM/NETGRAPH hardware driver may be too 
 work for little gain.

Actually writing a NATM driver is far easier than writing a HARP driver.
And Harti's newer drivers for ATM cards are, in fact, NATM drivers. You
only need to implement Netgraph hooks. You don't need to worry about
implementing Netgraph protocol nodes, generally.

You might want to contact Benno Rice, he was working on a software AAL5
kernel module to augment netnatm, which would help if you're targeting
the lower end ADSL hardware.

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


Re: resolving routes externally

2004-11-23 Thread Bruce M Simpson
On Tue, Nov 23, 2004 at 11:05:06AM +0200, Martin Eugen wrote:
 At the beginning my intention was to use the routing sockets
 mechanisms, and say, to issue a 'missing route' message to some
 userland daemon capable of resolving those complex addresses (the
 resolving mechanism is generally a lookup in a local DB). But then I

You're on the right track here. You might also wish to investigate
the RTM_RESOLVE mechanism.

 realized there is no (Am I missing it?) code in the routing modules
 that could make the thread handling the packet sleep until the
 userland daemon is looking up the route. (I'm also still not sure if a
 'netisr' thread is safe to sleep?) So I started to look at the ARP
 code, but it of course lacks the kernel - userland communication
 interface. I would appreciate any ideas about what would be the easier
 way to implement such a thing where the kernel could wait (up to some
 reasonable time-out) a userland daemon to install a new route.

If I understand correctly, you want the kernel to queue packets until
layer 2 address resolution is complete. Right now we don't do this. If
there is no route to a destination, packets will be dropped.

The ARP code implements a queue for each IP host address which is
exactly 1 mbuf long (see llinfo_arp-la_hold). This holds the most
recent packet that the host is attempting to transmit to the host
pending MAC address lookup. All other packets will be dropped.

Making a network stack thread sleep would be a Very Bad Idea. A more
appropriate approach would be to use a separate netisr queue for
packets which have pending external MAC address lookup. However,
rather than calling netisr_dispatch() directly, you would want to
call schednetisr() directly once the route resolution was complete.

I guess this is non-IP traffic, in which case making the modifications
which you need will probably be easier.

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


Re: tcsh fix

2004-11-12 Thread Bruce M Simpson
On Fri, Nov 12, 2004 at 01:50:24PM -0600, Kevin Lyons wrote:
 Presumably pure csh is the last stable release of csh before tcsh came 
 along.  Openbsd, netbsd, sun and sgi all seem to have been able to 
 settle on a csh.

I'm extremely happy with having tcsh instead of csh in the base system. As
others have said, if someone has an operational requirement for plain old
csh, they are free to install the port and make the appropriate links.

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


Re: tcsh fix

2004-11-12 Thread Bruce M Simpson
Hello,

Misunderstandings such as this seem to be all too common in volunteer
open source projects, sadly, and the resultant slagging match on
mailing lists is counterproductive for all concerned.

On Fri, Nov 12, 2004 at 04:53:58PM -0500, Charles Sprickman wrote:
 As an interested (and innocent) bystander, I'm not quite grasping why it's 
 an either/or proposition.  Why not just break the link, grab net/open's 
 /bin/csh and commit it?

Because we settled on tcsh 4 years ago, and no one has complained up
until now, and making such a change now means going through all the
vendor branch rigmarole for another shell in the base system, when
the vast majority of people using the system are happy with the
shells we already have, and alternatives are easily and readily
available from ports.

If person X wants shell Y which is not in the base system, and they
wish to use they are perfectly free to use ports or maintain a local
branch. The latter is non-trivial, the former, well, the time and
effort involved in maintaining a port is far lower, and a port
already exists for this particular case.

Being abusive towards the volunteers who maintain something largely
for free, and maintaining that something a bug when it isn't, when the
answer to person X's problems is right in front of them, doesn't
help anyone - it certainly doesn't help the person who wants the
functionality of shell Y, and it doesn't magically inspire the
volunteers who maintain the project to invest the non-trivial time
and effort in creating a CVS vendor branch to maintain shell Y,
which only person X has asked for.

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


Re: tcsh fix

2004-11-11 Thread Bruce M Simpson
On Fri, Nov 12, 2004 at 04:11:22AM +0100, Erik Trulsson wrote:
 Keep in mind that FreeBSD's /bin/sh is a more powerful shell than was
 available in, say, v7 Unix.

Also keep in mind that ash is not POSIX sh (at least not as completely
as one might like). This tends to bite me when using GNU autotools,
which are hardcoded to prefer bash by default.

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


Re: Where is the source to the system calls?

2004-11-07 Thread Bruce M Simpson
On Sun, Nov 07, 2004 at 04:29:42PM -0800, Dan Strick wrote:
 Does anyone know where the system calls are really defined?

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


c++filt is broken

2004-11-05 Thread Bruce M Simpson
c++filt is broken, at least on 5.3 and -CURRENT. It no longer builds
during a buildworld. This is really annoying for those of using the
base system compiler to build large C++ projects.

I've attached a Makefile which works for me; I haven't integrated it
into my local buildworld, though.

BMS
#   $XORP$

S=  /usr/src
.PATH:  $S/contrib/gcc

PROG=   c++filt
SRCS=   cp-demangle.c dyn-string.c
CFLAGS+= -DSTANDALONE_DEMANGLER
CFLAGS+= -Dxmalloc=malloc -Dxrealloc=realloc
LDADD+= -lgcc
NOMAN=  defined

test:   ${PROG}
${.OBJDIR}/${PROG}  ${.CURDIR}/sample

.include bsd.prog.mk
N11__gnu_debug14_Safe_iteratorIN10__gnu_norm14_List_iteratorIP7BGPPeerEEN15__gnu_debug_def4listIS4_SaIS4_E


pgpd4m13utwWf.pgp
Description: PGP signature


Re: Freebsd assembly programming - IN/OUT commands.

2004-10-17 Thread Bruce M Simpson
On Sun, Oct 17, 2004 at 09:46:29PM +0200, Jan Opacki wrote:
 Thanks for help. i386_set_ioperm() is exactly what i need.

I have to say though I've had processes dump core the first time I've
tried doing I/O port accesses after calling i386_set_ioperm() on 5.x
since 5.0. This behaviour is sporadic. With opening /dev/io, I have
had no problem.

Also, the /dev/io method appears to work on amd64, whereas the
i386_set_ioperm() method does not.

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


Re: How to access a device on LPC bus?

2004-10-17 Thread Bruce M Simpson
On Sun, Oct 17, 2004 at 01:50:11PM +0200, Thiemo Nordenholz wrote:
 beginner's question, maybe: How do I, from a device driver point of view,
 access a device attached to the Low Pincount (LPC) bus? 

Treat it as an ISA bus but write an ACPI attachment for it.
Look at src/sys/dev/fdc/fdc_acpi.c:fdc_acpi_probe() for an example.

 unknown pnpinfo _HID=WEC0518 _UID=0 at handle=\_SB_.C046.C059.C140

There appears to be a Linux driver for this, which gives you something
to work from.

 Now, to implement an identify function in a driver for this, I need to
 access data in the controller - but I don't have any information about its
 memory attachments... 

I'd suggest looking at that driver and accessing the registers you need to
identify the device sub-type in your attach function.

BMS


pgpE1xHFvjl04.pgp
Description: PGP signature


Re: execute a user process in the kernel

2004-09-25 Thread Bruce M Simpson
On Fri, Sep 24, 2004 at 06:21:25PM +0200, Dag-Erling Smørgrav wrote:
 You could, of course, write a kernel API for creating processes from
 scratch.  They'd still need a parent, but you can use init(8) (pid 1)
 for that.

If we were to implement POSIX spawn(), we'd need something like this.
So this may be worth looking at.

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


Re: execute a user process in the kernel

2004-09-25 Thread Bruce M Simpson
On Sat, Sep 25, 2004 at 01:35:07PM +0200, Dag-Erling Smørgrav wrote:
  If we were to implement POSIX spawn(), we'd need something like this.
 
 Uh, no.  posix_spawn(3) can be implemented entirely in userland and
 does not require any special kernel support.

Discussions with peter@ and others on IRC have been ongoing regarding doing
it in kernel space, so as to avoid unnecessarily expensive VM fork operations
when 'spawning' a process.

I'd be interested to hear more about your proposal for doing this in userland.

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


Re: Global (non _KERNEL) place for sockaddr_union?

2004-09-23 Thread Bruce M Simpson
Greetings earthmen,

On Thu, Sep 23, 2004 at 02:14:00AM +0200, Max Laier wrote:
 As no real solution has come up and we couldn't agree what to do with it 
 either, I'll resort to an easy hack: 
  http://people.freebsd.org/~mlaier/sockaddr_union.fix.diff
...
 Any objections? [ I know it's ugly already. ]

Looks fine to me; I agree that this workaround is not ideal but it is
acceptable given the circumstances.

Regards,
BMS


pgp6f5B4E5OKz.pgp
Description: PGP signature


Re: execute a user process in the kernel

2004-09-23 Thread Bruce M Simpson
On Thu, Sep 23, 2004 at 08:18:14AM +, Gordon David wrote:
 Kqueue is a good method to notify the user. But I want the code in the 
 kernel directly calls a user program.

This is Very, Very Hard indeed, because it's not something supported by
the system, but it should be possible. Look at create_init() and
start_init() and see if they can be adapted to your needs. The hard
part here is building the process image. Good luck.

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


Re: Error 1802: IBM T41 doesn't like other network cards

2004-09-23 Thread Bruce M Simpson
Hi,

On Thu, Sep 23, 2004 at 09:57:25PM +1000, Phillip Crumpler wittered thus:
 Anyone else has similar problems? BMS@ reported ditching the Centrino 
 card in his T40 but didn't mention if he replaced it with something else.

I used an official IBM Atheros part, so I didn't run into this problem.

 http://www.ussg.iu.edu/hypermail/linux/kernel/0406.1/1048.html

The quickest way to do this is to use the DOS program linked to above.

Porting the CMOS code to FreeBSD is fairly trivial for someone who knows,
though, but you probably don't want to wait.

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


Re: Global (non _KERNEL) place for sockaddr_union?

2004-09-21 Thread Bruce M Simpson
On Mon, Sep 20, 2004 at 02:50:40AM +0200, Max Laier wrote:
 My question now is, what would be a good place to define this? Are there any 
 fromal standarts that might define it already? (Couldn't find anything) Is 
 there anything else that I must consider?

I think Brooks' recommendation is sound and should probably be followed
as it's fairly close to my original recommendation to you in private.

The problem is that the definition of the union depends on what you wish
to use it for, and which address families are visible to the application
or kernel module which is using the definition.

You may find that such a definition has to have conditionalized members.
This is usually not a problem so long as they are all the same size. And
a sockaddr union embedded in a struct probably should have a member with
type 'struct sockaddr_storage' if it's to support all address families
in future, although this commits more storage in the enclosing struct
and may waste space in some cases.

As you point out, you cannot do this in pf, as it defeats the intent of
keeping larger members out of the table in the first place, and the union
is there to make some casts go away.

If it's any consolation, I'm going through very similar pain with XORP's
new firewall manager right now with respect to address families (and
templatized C++ classes).

Regards,
BMS


pgpwv1vXE9d9A.pgp
Description: PGP signature


Re: ZFS

2004-09-16 Thread Bruce M Simpson
On Thu, Sep 16, 2004 at 11:00:44AM -0500, Sam wrote:
 Yes, it's a single filesystem. But the storage most likely won't be all
 in one place. Making it look like it's accessible from one place is a
 good thing.
 
 ... are you hinting at multiple globally remote block accessible storage
 sets?  Otherwise I'm at a loss.

To the best of my knowledge, no, ZFS/DFS is only accessible locally on
the machine it's mounted on. But the block storage can be scattered
across multiple devices. It can be exported via NFS, this much I know.

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


Re: ZFS

2004-09-16 Thread Bruce M Simpson
On Thu, Sep 16, 2004 at 11:12:16AM -0400, Kevin A. Pieckiel wrote:
 Where on earth would you find a disk system that can store 2^64 bytes of
 data or larger, anyway?  Don't physical and technological limitations
 limit the total capacity of even the largest hard drives now available?
 It would take millions of drives, or more, to create a single 2^64 byte
 logical drive.

You can bet that somebody, somewhere, needs this right now. And someone
will definitely need it in the next 5-10 years.

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


Re: Booting encrypted

2004-09-07 Thread Bruce M Simpson
On Tue, Sep 07, 2004 at 01:54:43PM -0700, [EMAIL PROTECTED] wrote:
 If the authorization mechanism is limited to plain text, then yes. I know
 that strings can be used to attempt to find the passphrase in the load,
 but there may be ways to prevent the passphrase from being retrieved in
 this manner.

On the other hand, you could use TCPA. Support for the TCPA chips found in
many recent IBM machines, particularly the ThinkPad T4x series, was written
for NetBSD by the folks at CITI.  It's on my wishlist.

You could probably teach GDBE about TCPA key retrieval, but the upshot is,
you still need to log in to the TCPA chip. However, if you activated TCPA
and only allowed it to boot your FreeBSD-derived product OS, by means of
their signature mechanism, then you might well achieve your stated aims.

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


Re: Driver for Thinkpad Hotkeys.

2004-08-08 Thread Bruce M Simpson
On Mon, Aug 09, 2004 at 04:03:18AM +0200, Arne Schwabe wrote:
 IIrc correct the WLAN indicator is wired to the minipci for Thinkpads,
 at least the linux madwifi (which is basically our ath driver but our
 ath has not been updated for some very long time) has support for the
 IBM thinkpad wlan led. Maybe that is not the only method of talking to
 the LED :)

GPIO pins, twiddled by the driver, according to Sam. The madwifi stuff
does this. A more significant backport of ath features should really
be done. If I find time, I'll certainly help, given that ath is now
my primary wireless connection.

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


Re: regarding timeout/untimeout kernel functions

2004-07-22 Thread Bruce M Simpson
On Thu, Jul 22, 2004 at 09:56:00PM -0500, Dan Nelson wrote:
 You could also use the kqueue/kevent functions to queue up an arbitrary
 number of timer events in a single process.

I wrote a small routing daemon which uses kqueue/kevent to fire a period
timer on a quantum which in turn calls into a timer list module I wrote,
which can either use the kevent quantum, or multiplex on a single itimer.

It's pretty basic and probably not foolproof, but it seems to work well.

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


Article on Sun's DTrace

2004-06-29 Thread Bruce M Simpson
This recently caught my eye:
http://www.samag.com/documents/s=9171/sam0406h/0406h.htm

There are a number of good sounding suggestions in there.

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


Re: SPDIF capture device?

2004-06-20 Thread Bruce M Simpson
Hello,

On Fri, Jun 18, 2004 at 01:56:25PM +0200, Ing.Richard Andrysek wrote:
 I've read your question about SPDIF capture device on freebsd. I am 
 currently looking for similar device.Have you found such one? Can you 
 access subcode etc.?

The Soyo Dragon Plus! K7V has a SPDIF input/output; this uses the
snd_cmi driver. However, I think some machine specific incantations
are necessary to use SPDIF mode, and I don't know what these are.

I have such a board but it's not in Desktop use (it's in my CVS server).

Some reverse engineering is probably needed here, but if the Linux
drivers support this and a change can be crossported easily, I'll
happily commit it if people have the means to test it.

Regards,
BMS


pgpklEdbveJRY.pgp
Description: PGP signature


Re: memory mapped packet capturing - bpf replacement ?

2004-06-14 Thread Bruce M Simpson
On Mon, Jun 14, 2004 at 10:15:14AM -0700, Julian Elischer wrote:
 don't forget that bpf is not copying the entire packet, just the
 header..

If you look at Sergey's benchmark.c, you will see that the snaplen was
set to 32KB.

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


Re: memory mapped packet capturing - bpf replacement ?

2004-06-14 Thread Bruce M Simpson
On Mon, Jun 14, 2004 at 08:38:57AM -0400, Ed Maste wrote:
 Hello Sergey.  I haven't looked at your code, but I'll provide 
 some comments, having implemented a mmaped ringbuffer BPF 
 replacement myself.

We've had some prior interest in this. Do you have patches? If so, I'd be
more than happy to look at them.

Linux has something similar, but when I looked at the mechanism involved,
I was loathe to adopt the same logic because the buffer(s) involved were
allocated from userland and then mapped accordingly; we generally can't
afford to take a page fault in that path, for mutex related reasons.

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


Re: api for sharing memory from kernel to userspace?

2004-05-20 Thread Bruce M Simpson
On Wed, May 19, 2004 at 03:29:09PM -0700, Steve Watt wrote:
 On Wed, May 19, 2004 at 05:29:07AM -0700, Alfred Perlstein wrote:
 + I need to share about 100megs of memory between kernel and userspace.
 +
 + The memory can not be paged and should appear contig in the process's
 + address space.  Any suggestions?
 +
 
 The way we accomplished this in some other operating system was to
 create a shared memory segment with an implementation-reserved
 name, and then have the application shm_open the name and mmap it in.
 
 Shouldn't be hard with a device driver.

This sounds like the way to go.

The way I achieved this with a PCMCIA memory card was to kmem_alloc_nofault()
a range and then pmap_map() it, then handle mmap() as per the regular
character device case.

Do bear in mind that 100 megs is quite large in relative terms, so it's
possible that kmem_alloc_nofault() would fail.

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


Re: passing messages to routing sockets

2004-04-10 Thread Bruce M Simpson
On Fri, Apr 09, 2004 at 08:02:30PM +0300, Vlad GALU wrote:
   I understand that in order to add a new route to the routing
 table, one must fill a buffer with an ifa_msghdr header, followed by three
 socked adddress structures, representing the destination net/ip, the
 netmask and the gateway.
[routing table suckiness snipped]
   Could anyone provide a quick/small example on how to fill this
 member ? I don't really understand what I should write into it.

It's a sucky one and I had to stare at src/sbin/route/* for a while til
the penny dropped. The netmasks in particular are packed in in a format
which isn't immediately obvious.

Have a look at the attached code, in particular, reply_rtmsg_resolve().

Also have a look at Section 19.11 of TCP/IP Illustrated Volume 2, and
Section 18.9 of UNIX Network Programming 3e Vol 1.

The API sucks, and it's something we'd like to change in future.

Regards,
BMS
/*  $FreeBSD$ */

/*
 * This is a hack to demonstrate the concept of hooking for the
 * RTM_RESOLVE message being sent from the FreeBSD routing code,
 * as a means of looking up routes on demand using a routing protocol
 * such as AODV.
 * This code will probably be vastly cleaned up and tested more thoroughly
 * before being used as the basis for a user-space BSD AODV implementation.
 */

/*
 * Copyright (c) 2003 Bruce M. Simpson [EMAIL PROTECTED]
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in the
 *documentation and/or other materials provided with the distribution.
 * 3. All advertising materials mentioning features or use of this software
 *must display the following acknowledgement:
 *This product includes software developed by Bruce M. Simpson.
 * 4. Neither the name of Bruce M. Simpson nor the names of co-
 *contributors may be used to endorse or promote products derived
 *from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY Bruce M. Simpson AND CONTRIBUTORS
 * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
 * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL Bruce M. Simpson OR CONTRIBUTORS
 * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
 * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
 * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
 * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
 * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 * POSSIBILITY OF SUCH DAMAGE.
 */

#include sys/param.h
#include sys/file.h
#include sys/socket.h
#include sys/sysctl.h
#include sys/ioctl.h
#include sys/sysctl.h
#include sys/types.h
#include sys/signal.h

#include net/if.h
#include net/if_var.h
#include net/if_mib.h
#include net/if_types.h
#include net/if_dl.h
#include net/route.h
#include netinet/in.h
#include netinet/if_ether.h
#include arpa/inet.h
#include netdb.h

#include ctype.h
#include err.h
#include errno.h
#include paths.h
#include signal.h
#include stdio.h
#include stdlib.h
#include string.h
#include sysexits.h
#include unistd.h
#include ifaddrs.h

union sockunion {
struct  sockaddr sa;
struct  sockaddr_in sin;
struct  sockaddr_dl sdl;
struct  sockaddr_storage ss;
};
typedef union sockunion sockunion_t;

void usage(void);
int add_xresolve_route(char *ifname, struct sockaddr_in *sin, int bits);
int inet_cidr_aton(char *s, struct in_addr *pin, int *bits);
int create_if(char *ifname);
int destroy_if(char *ifname);
int if2sockaddr(char *ifname, struct sockaddr_dl *sdl);
int handle_rtmsg(struct rt_msghdr *rtm, int msglen);
int handle_rtmsg_resolve(struct rt_msghdr *rtm, int msglen);
int reply_rtmsg_resolve(struct sockaddr_in *sin);

/*
 * We check for the existence of ifname.
 */
#if 1
#define _IFNAME disc1
#else
#define _IFNAME lo0
#endif

int rtsock = -1;
int created = 0;
char *ifname = _IFNAME;

void
sighand_term(int sig)
{
/*
 * Destroying an interface is sufficient to delete the routes
 * pointing to it.
 */
if (created)
destroy_if(ifname);

exit(EXIT_SUCCESS);
}

void
setup_signals(void)
{
struct sigaction sa, osa;

sa.sa_handler = sighand_term;
sa.sa_flags = 0;
sigemptyset(sa.sa_mask);

sigaction(SIGTERM, sa, osa);
sigaction(SIGINT, sa, osa);
sigaction(SIGQUIT, sa, osa

Re: wireless usb atmel driver

2004-04-02 Thread Bruce M Simpson
On Fri, Apr 02, 2004 at 04:25:08PM +0300, Anton Alin-Adrian wrote:
 I am killing myself trying to compile http://www.vitsch.net/bsd/atuwi/ 
 driver on 5.2.1-RELEASE.

Try the atuwi from my perforce tree.

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


Re: Determining a program's shared libraries at runtime

2004-03-31 Thread Bruce M Simpson
On Wed, Mar 31, 2004 at 02:55:47PM -0500, Mike Heffner wrote:
 Is there a method in FreeBSD for a program to retrieve the current list of
 dynamic shared libraries it is linked against or has dlopen()'d?

/proc/pid/map should give you what you need, but it needs to be read
atomically, i.e. you can't use more than one read() call to retrieve the
information so you probably want to cp it to a temporary file and read it.

This also requires that /proc be mounted, which is not the default behaviour
under -CURRENT any more.

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


Re: events when (de)associating or when cable is (un)plugged

2004-03-27 Thread Bruce M Simpson
On Sat, Mar 27, 2004 at 03:37:44AM +0100, Dirk-Willem van Gulik wrote:
 Suleiman,
 
 Thanks for all the help  - I just hacked up the patch below and took
 http://green.homeunix.org/~green/linkwatcher.c for  testing. I also
 had to add the LINKUP/DOWN in some non-mii using ethernet
 cards (as only miibus(4) seems to issue this event).

Nice! I'll take a more indepth look at this when less pressed. Keep on hacking.
Would be nice to hook up with the WirelessLeiden folks too...

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


Re: Intel i8xx watchdog driver

2004-03-25 Thread Bruce M Simpson
On Thu, Mar 25, 2004 at 05:40:33PM -0500, Don Bowman wrote:
 SMI under freebsd? Ha ha... Good luck! It didn't look very
 easy. The SMM, for those who don't know it, is a virtual
 86, real-mode thing, at a location in ram which is locked
 and unaccessible unless you are in smm mode :) If you
 are lucky, your bios didn't lock you out of it.

I wrote code to unlock the SMM within FreeBSD last summer on an IBM T22
with the 440BX chipset. Here it is.

BMS
/*  $FreeBSD$ */

/*
 * A tool for FreeBSD to discover SMRAM on i440BX based motherboards.
 * This isn't finished or complete, left as exercise for the reader.
 */

/*
 * Copyright (c) 2003 Bruce M. Simpson [EMAIL PROTECTED]
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in the
 *documentation and/or other materials provided with the distribution.
 * 3. All advertising materials mentioning features or use of this software
 *must display the following acknowledgement:
 *This product includes software developed by Bruce M. Simpson.
 * 4. Neither the name of Bruce M. Simpson nor the names of co-
 *contributors may be used to endorse or promote products derived
 *from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY Bruce M. Simpson AND CONTRIBUTORS
 * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
 * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL Bruce M. Simpson OR CONTRIBUTORS
 * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
 * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
 * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
 * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
 * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 * POSSIBILITY OF SUCH DAMAGE.
 */

#include sys/param.h
#include sys/types.h
#include sys/fcntl.h
#include sys/pciio.h
#include sys/mman.h
#include sys/memrange.h

#include fcntl.h
#include stddef.h
#include stdlib.h
#include stdio.h
#include unistd.h
#include strings.h

#include machine/sysarch.h
#include machine/vm86.h
#include machine/cpufunc.h

#ifndef _DEV_PCI
#define _DEV_PCI /dev/pci
#endif

#ifndef _DEV_MEM
#define _DEV_MEM /dev/mem
#endif

/*
 * It appears as though my ThinkPad does not map SMRAM at the default
 * location. This isn't too much of a surprise. Firmware is responsible
 * for reprogramming the default location, and has to issue an SMI
 * during boot in order to do this. The actual SMI handler code is
 * located at SMBASE+0x8000. A quick way of issuing the SMI is to use
 * the on-chip APIC. A number of vendor BIOS do it this way.
 *
 * Can we discover if the host bridge remaps SMBASE? Yes.
 * on the i440BX host bridge, check the SMRAMC register.
 *
 * There are two modes: Compatible and Extended SMRAM. Compatible mode
 * is meant to be backwards compatible with older BIOS PM code.
 * The C_BASE_SEG bits will tell you where the SMRAM memory
 * really is. Setting D_OPEN to high will let you get at the SMRAM memory.
 *
 * If your VGA controller mapping is active, it would be a good idea not
 * to use it while you're doing this.
 *
 * My ThinkPad's BIOS doesn't set the lock bit.
 * My ThinkPad's BIOS uses traditional SMRAM semantics.
 * i440BX Compatible SMRAM is hardwired to 0xA-0xB.
 *
 * By poking D_OPEN to 1, I was able to extract the SMRAM segment from
 * my machine.
 *  # pciconf -r -b pci0:0:0 0x72
 *  0a
 *  # pciconf -w -b pci0:0:0 0x72 0x4A
 *  # dd bs=0x1000 skip=0xA0 count=0x20 if=/dev/mem of=./foo
 *  # pciconf -w -b pci0:0:0 0x72 0x0A
 */

#define I440BX 1

#ifdef DEF_SMM
#define SMBASE  0x3UL   /* default IA-32 SMBASE location */
#define SMSIZE  0x1UL   /* default size of SMM area */
#endif

#ifdef I440BX
#define SMBASE  0xAUL   /* default i440BX SMBASE location */
#define SMSIZE  0x2UL   /* default size of SMM area (128KB) */
#endif

#ifdef I440BX_HIGH
#define SMBASE  0x100AUL   /* default i440BX SMBASE location */
#define SMSIZE  0x2UL   /* default size of SMM area (128KB) */
#endif

#define I440BX_VENDOR   0x8086  /* Intel */
#define I440BX_DEVICE   0x7190  /* I440BX host-to-pci bridge */

#define CSR_SMRAMC  0x72/* System Management RAM Control */
#define CSR_ESMRAMC 0x73/* Extended SMRAM Control */

#define SMRAMC_D_OPEN   0x40
#define

Re: Intel i8xx watchdog driver

2004-03-25 Thread Bruce M Simpson
Correction...

On Thu, Mar 25, 2004 at 11:26:59PM +, Bruce M Simpson wrote:
 I wrote code to unlock the SMM within FreeBSD last summer on an IBM T22
  ^^ discover and map.
 with the 440BX chipset. Here it is.

Half asleep here. Doh!

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


Re: Intel i8xx watchdog driver

2004-03-12 Thread Bruce M Simpson
On Thu, Mar 11, 2004 at 07:07:36PM -0600, Wm. Daryl Hawkins wrote:
 I would love to incorporate it in both source trees if possible.  Before
 it goes into current, I need to make some changes so that it will work
 with Poul-Henning Kamp's new watchdog driver model.  Hopefully, I'll get
 to work on that some tomorrow.  I'll release a new version for current
 as soon as it's ready.

Excellent, I was just going to suggest that.

On the subject of 'bits and bobs that hang off buses', Stacy Millions wrote
a driver for the FWH RNG, and Doug Ambrisko rolled some code to flash the
FWH on an i845 chipset if memory serves...

I am happy to look at your code once it fits better with what we currently
have providing I have time.

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


Re: Kernel SysV IPC defaults.

2004-03-04 Thread Bruce M Simpson
On Wed, Mar 03, 2004 at 05:42:43PM +, Chris Smith wrote:
 Consider  MSGMAX (max bytes in a message) and MSGMNB (max bytes in a queue)
 The defaults are MSGMAX  MSGMNB, which is clearly backwards.

I see this. How about the attached patch?

I can understand people still using the SYSV IPC mechanisms for the sake of
compatibility, but I suspect the purists are loathe to touch it.

BMS
Index: src/sys/kern/sysv_msg.c
===
RCS file: /home/ncvs/src/sys/kern/sysv_msg.c,v
retrieving revision 1.52
diff -u -r1.52 sysv_msg.c
--- src/sys/kern/sysv_msg.c 7 Nov 2003 04:47:14 -   1.52
+++ src/sys/kern/sysv_msg.c 4 Mar 2004 13:46:59 -
@@ -72,15 +72,15 @@
 #ifndef MSGSEG
 #define MSGSEG 2048/* must be less than 32767 */
 #endif
-#define MSGMAX (MSGSSZ*MSGSEG)
-#ifndef MSGMNB
-#define MSGMNB 2048/* max # of bytes in a queue */
-#endif
 #ifndef MSGMNI
-#define MSGMNI 40
+#define MSGMNI 40  /* # of message queue identifiers */
 #endif
 #ifndef MSGTQL
-#define MSGTQL 40
+#define MSGTQL 40  /* max messages in system */
+#endif
+#define MSGMAX (MSGSSZ*MSGSEG) /* max # of bytes in a message */
+#ifndef MSGMNB
+#define MSGMNB (10*MSGMAX) /* max chars in a queue */
 #endif
 
 /*
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Accessing sysctls from kernel

2004-02-26 Thread Bruce M Simpson
On Thu, Feb 26, 2004 at 02:10:40PM +0100, Ivan Voras wrote:
 In sys/sys/sysctl.h I see function kernel_sysctlbyname() that looks (to 
 me) to be intended for accessing sysctl values from kernel, but for it's 
 first parameter it requires a struct thread *td.
 
 What should I pass to it? (I'm calling it from inside a screensaver module)

You could try lying about which thread you are, when you aren't in
a userland thread:

Cscope tag: kernel_sysctlbyname
   #   line  filename / context / line
   1728  /sys/dev/vinum/vinumio.c vinum_scandisk
 error = kernel_sysctlbyname(thread0, kern.disks, NULL,
   2741  /sys/dev/vinum/vinumio.c vinum_scandisk
 kernel_sysctlbyname(thread0, kern.disks, devicename,
   3305  /sys/i386/i386/elan-mmcr.c init_AMD_Elan_sc520
 i = kernel_sysctlbyname(thread0, machdep.i8254_freq,

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


Re: Local APIC on FreeBSD/i386

2004-02-23 Thread Bruce M Simpson
On Mon, Feb 23, 2004 at 10:20:57AM -0500, John Baldwin wrote:
 As of 5.2, the 5.x branch will use the local APIC on UP systems.

Yay! Hopefully my pseudo-NMI-on-ThinkPad-button hack to the ACPI DSDT will
work..

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


Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5)

2004-02-16 Thread Bruce M Simpson
On Mon, Feb 16, 2004 at 07:11:16PM +0100, Dag-Erling Smørgrav wrote:
 It can't possibly hurt.  If the stack is already aligned on a better
 boundary (64 or 128 bytes), it is also aligned on a 32-byte boundary
 since 64 and 128 are multiples of 32, and the patch is a no-op.  If
 only a 16-byte alignment is required, a 32-byte alignment wastes a
 small amount of memory but does not hurt performance.  I believe that
 less-than-16 (and possibly even less-than-32) alignment is pessimal on
 all platforms we support.

I'm not happy with the patch as-is and would be happier if a cleaner
MI-way of expressing this were found.

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


Re: Adding 'realclean' target to /usr/src/Makefile

2004-02-15 Thread Bruce M Simpson
On Sun, Feb 15, 2004 at 02:42:07AM -0500, Garance A Drosihn wrote:
 It occurs to me that the simple, reliable solution to this is to
 add a 'realclean' target to /usr/src/Makefile, such as:

I don't have a problem with this.

However, on a related but somewhat separate note:

It would be helpful if it were pointed out in documentation somewhere
that the path to the compile and source directories, when doing NFS
kernel installs, has to be identical to those which were in effect on
the build box due to the treatment of MAKEOBJDIRPREFIX during the modules
build (and subsequent modules/* path creation).

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


Re: BDM under current

2004-02-14 Thread Bruce M Simpson
On Fri, Feb 13, 2004 at 10:02:47PM -0500, James Housley wrote:
 does anyone know whether i can use gdb + bdm under freebsd ?
 
 Probably not, I had it working well under 3.x, never really got it working 
 in 4.x

I wouldn't mind following this up, alas, I don't have any BDM gear here. It
is something I'd really like to get into though.

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


Re: FreeBSD 5.2-current problem in Dell Poweredge 1600SC

2004-02-13 Thread Bruce M Simpson
On Fri, Feb 13, 2004 at 05:42:01PM +0800, Ganbold wrote:
 I installed FreeBSD 5.2 on Dell Poweredge 1600SC. However FreeBSD doesn't 
 recognize
 network card. It has onboard Intel Pro 1000 card.

You probably want to try loading the if_em.ko module. I recently installed
4.9 on a newer Optiplex machine with an em(4) card and noticed that
sysinstall didn't pick it up right away, so I put if_em.ko on an MSDOS
floppy and loaded it from within the 'post-install options' menu before
installing (somewhat confusing).

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


Re: XL driver checksum producing corrupted but checksum-correct packets

2004-01-27 Thread Bruce M Simpson
On Sun, Jan 25, 2004 at 01:13:28PM -0600, Mike Silbersack wrote:
 I suppose that one thing we could do in the long run to help detect this
 sort of corruption would be to import OpenBSD's TCP MD5 support and ensure
 that packets which fail the md5 or fail the checksum are logged so that
 they can be investigated.
 
 Of course, that's adding data to the packet, and heisenberg wouldn't be
 too happy about that. :)

I'm porting this right now. It's a bit different for us...

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


Re: TCP MD5 (was Re: XL driver checksum producing corrupted but checksum-correct packets)

2004-01-27 Thread Bruce M Simpson
On Sun, Jan 25, 2004 at 07:59:32PM +, Aled Morris wrote:
 If you're talking about RFC2385 style MD5 as used for BGP authentication,
 I'd pay someone to make that work on FreeBSD (with Zebra/Quagga.)

Someone already is, and I have patches for Quagga/Zebra ongoing... (how
do you think I'm testing it? :-))

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


Re: XL driver checksum producing corrupted but checksum-correct packets

2004-01-26 Thread Bruce M Simpson
On Sun, Jan 25, 2004 at 01:13:28PM -0600, Mike Silbersack wrote:
 I suppose that one thing we could do in the long run to help detect this
 sort of corruption would be to import OpenBSD's TCP MD5 support and ensure
 that packets which fail the md5 or fail the checksum are logged so that
 they can be investigated.
 
 Of course, that's adding data to the packet, and heisenberg wouldn't be
 too happy about that. :)

I'm porting this right now. It's a bit different for us...

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


Re: TCP MD5 (was Re: XL driver checksum producing corrupted but checksum-correct packets)

2004-01-26 Thread Bruce M Simpson
On Sun, Jan 25, 2004 at 07:59:32PM +, Aled Morris wrote:
 If you're talking about RFC2385 style MD5 as used for BGP authentication,
 I'd pay someone to make that work on FreeBSD (with Zebra/Quagga.)

Someone already is, and I have patches for Quagga/Zebra ongoing... (how
do you think I'm testing it? :-))

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


Re: freebsd-hackers Digest, Vol 42, Issue 6

2004-01-11 Thread Bruce M Simpson
On Fri, Jan 09, 2004 at 03:57:07PM +, YACINE GHANJAOUI wrote:
 when trying to intercept UDP packet after changing the protocol number
 from 17 to a user one (99) in the ip_input.c file. when trying to
 regenrate the packet after inserting some bit errors an error message
 appears in the reciever telling that The udp checksum is incorrect even if
 i just change the ip Header.
 What do you think the problem is?

You didn't read how UDP checksums were calculated, did you? Here is one free
clue: Look at the definition of in_pseudo() and where it is used.

Use the source. look!

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


Re: switching between groups

2004-01-06 Thread Bruce M Simpson
On Tue, Jan 06, 2004 at 11:14:06AM -0500, Adil Katchi wrote:
 I was just wondering if anyone has any ideas how it's possible for a user
 that belongs to multiple groups to somehow limit his or her own capabilities
 by using only one of the n groups that they belong to and be able to switch
 between these groups?  For example, if userA belongs to groupA, groupB and
 groupC, can userA enter a mode that would force it to only belong to groupA
 (or groupB, or groupC)?  UserA whould be able to switch between these groups
 and back to normal (ie. belong to all groups).

newgrp(1) could be hacked to do this fairly easily. Currently it preserves
supplemental group memberships. An option to discard supplementals could
be added.

Or just call setgroups() with a no-op group-list vector and then setgid()/
setegid() from within your application.

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


SGI ARC x86 boxen diffs

2004-01-02 Thread Bruce M Simpson
I've burned up too much time over the holidays on trying to get our loader
pointed to ARC x86 on the SGI Visual Workstation, and didn't really get
anywhere.

If anyone has such a box and wants a starting point, go here:-
http://people.freebsd.org/~bms/dump/loader-arc-x86-sgi.diff

You'll need to install devel/mingw32-binutils.

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


Re: natd + ipfw question

2003-12-23 Thread Bruce M Simpson
On Tue, Dec 23, 2003 at 11:54:39AM -0500, Leo Bicknell wrote:
 doesn't?  Yes, I want to do something fancier treating inbound and
 outbound traffic differently, but this basic case doesn't seem to
 work, and it seems to me like it should.  What am I missing?

Have you configured IPFW2 (if running 4.x) into the kernel and rebuilt
the appropriate pieces of world?

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


Re: adding more ram

2003-12-10 Thread Bruce M Simpson
On Wed, Dec 10, 2003 at 09:41:11AM -0500, Bill Vermillion wrote:
 Systems such as the Irix I used before moving the servers to FBSD
 around 1996 - reserverd swap space for applications when the
 application started up so those needed large swap space.  Often it
 was never used, but the design allocated it anyway.

I also remember what fun could be had on an IRIX 5.3 machine with leaky
X11 servers. SGI's Xsgi memory leaks on that IRIX release were particularly
noticeable when using it on a 24-bit Indy and viewing lots of porn^Wgraphics.

This seemed to be down to Xsgi reserving lots of swap in lieu of a heavy
backing store workload, which it didn't actually use. And this often brought
Xsgi crashing to a halt anyway.

So I would have mixed feelings about adopting such a scheme in future.

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


ifconfig(8) refactoring -- YACC grammar now online

2003-11-30 Thread Bruce M Simpson
Hi all,

As per Sam's suggestion, I've been working on refactoring ifconfig(8),
which has grown increasingly large and unwieldy. Part of the effort has
been to get a handle on all of the options we currently support; so I've
written a YACC grammar for it.

This is my first serious bit of work with YACC so I'd appreciate any
feedback you can give.

I've uploaded the grammar, makefile, and all the EPS files, here:-
http://people.freebsd.org/~bms/dump/nifconfig/ (for browsing)
http://people.freebsd.org/~bms/dump/nifconfig.tgz  (tarball)

I've also generated a PDF file you can view which shows you syntax diagrams
for each part of the parse tree. This is here:-
http://people.freebsd.org/~bms/dump/nifconfig/all.pdf

I can't quite seem to persuade Ebnf2ps to generate a recursive unfolding
of all productions from argv downwards, though, that would be most helpful.

This involved rolling two ports, epsmerge and Ebnf2ps, to visualize the
syntax graphically. I will commit these ports once the freeze as over as
they're likely to be useful to a lot of people.

Please let me know your thoughts on this.

Thanks,
BMS


pgp0.pgp
Description: PGP signature


Re: ifconfig(8) refactoring -- YACC grammar now online

2003-11-30 Thread Bruce M Simpson
On Sun, Nov 30, 2003 at 01:12:42PM +0100, Andre Oppermann wrote:
 What I've thinking about a lot is to make the networking system and
 ifconfig sort of class-based like newbus and geom.

Look at: http://people.freebsd.org/~bms/dump/nifconfig/nifconfig-design.txt

There is a pending change to if_gre to enable it to be easily classified
in this way; ifconfig would simply query the interface for its if_type. This
is one way to do it without having to change struct ifnet. We could add a
new field, but avoiding changing the ABI is a Good Thing.

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


Re: ifconfig(8) refactoring -- YACC grammar now online

2003-11-30 Thread Bruce M Simpson
On Sun, Nov 30, 2003 at 02:20:50PM -0500, Robert Watson wrote:
 if_type seems like it will work for high level classes of interfaces, but
 something more fine-grained will be required for interfaces that implement
 multiple classes or subclasses (i.e., 802 generally, and also 802.11b).

The idea just now is we look at if_media if we need to get specific with
physical interfaces.

tap would seem to be missing from my list, actually; I note it's used
to provide VMware support in the absence of Netgraph, amongst other things.

 Or likewise, tap interfaces might implement 802 generally, but also
 if_tap-specific primitives.  Do we need to probe by-name for capabilities
 using interface ioctls, or return a list of implemented
 interfaces/classes to allow things to be a bit more multidimensional?

That might work well, actually -- I already added a MIB to rtsock to deal
with our lack of reporting multicast group memberships, I see no reason
not to add one to enumerate loaded interface classes.

OTOH, for the 'could load kld' case, this falls down, until the instance
is created, either through cloning or completing ifattach() for a physical
interface -- but if CREATE is a separate operation this isn't a problem,
it is a problem if we want to say something like this in one go:-

  ifconfig gif0 create tunnel 1.2.3.4 5.6.7.8 10.0.0.1 10.0.0.2

Then you do need a means for the ifconfig instance to ask gif0 if it speaks
'tunnel-ese' once it's loaded.

I have to find an abstraction to comfortably deal with this stacking of
properties/methods, simple polymorphism (a la Java 'implements interface')
springs to mind.

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


Re: Making a FreeBSD DVD

2003-11-23 Thread Bruce M Simpson
On Sun, Nov 23, 2003 at 09:28:37PM -0500, Leo Bicknell wrote:
 I'd like to make my own distribution DVD's.  I know how to make
[snip]

I'm intrigued by this. Is it possible to build DVDs which will boot on
i386 and/or a variety of architectures? FAQ pointers welcome...

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


Re: Conflict between sys/sysproto.h stdio.h ... ?

2003-11-18 Thread Bruce M Simpson
On Tue, Nov 18, 2003 at 12:39:37AM -0800, lucy loo wrote:
 I am writing a kernel loadable module to reimplement some system calls. I have 
 included sys/sysproto.h, sys/systm.h, etc. -- very standard header files for kld 
 implmentation. I also want to do file i/o in this module, therefore I need to 
 include stdio.h. But it obviously conflicts with those sys/..., and make won't 
 pass. 

RTFM - particularly style(9), do not include userland headers in the kernel.

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


Re: secure file flag?

2003-11-18 Thread Bruce M Simpson
On Tue, Nov 18, 2003 at 04:31:32PM -0800, Rayson Ho wrote:
 I am wondering if it is useful to have a secure file flag??
...
 e.g. when deleting a secure file, the OS will overwrite the file with
 random data.

I've got patches somewhere for zeroing out memory mappings in this way, but
they are incomplete. :-(

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


Re: Driver question

2003-11-10 Thread Bruce M Simpson
Craig,

On Sat, Nov 08, 2003 at 10:11:22PM -0500, Craig StJean wrote:
 I have a prism2 USB wireless device. I've never written drivers before but I have 
 been developing for the past 8 years. Could someone guide me to a website or 
 something that would help me write a USB wrapper for the wi device? I have a copy of 
 the old uwi driver which is now broken so it may help me along the way aswell.

I'd suggest co-ordinating your efforts with Stuart Walsh who wrote the atwi
USB driver. This is for atmel USB parts, but there are certain devices with
the same VID/PIDs which are prism2 USB devices. His code might serve as a
good starting point for you.

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


Re: kernel malloc usage

2003-11-03 Thread Bruce M Simpson
On Mon, Nov 03, 2003 at 10:51:58AM +0100, Gerald Heinig wrote:
 Is this true? I seem to remember that FreeBSD has a slab allocator,
 which IIRC is particularly good at allocating small chunks.

You don't specify which version of the kernel you're programming to; so
I'll assume 5.x.

If your allocations are of similar size, then consider using the zone
allocator; I believe this implements a slab-like algorithm.

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


User asks: can we decouple device vendor IDs from drivers?

2003-10-31 Thread Bruce M Simpson
Hi,

This sounds like one for the NEWBUS people.

BMS
---BeginMessage---
In message [EMAIL PROTECTED], Bruce M Simpson wrote:

Hiya

To follow up what I said down the pub...

The file in solaris i was referring to is called /etc/driver_aliases

do a search to find out about it.

Looking at the mess in FreeBSD device drivers and how the drivers
decide to attach to a device or not, then a lot of effort would
be needed to clean those up, but should an alias file such as the
solaris one exist in FBSD, IMHO it would make the life of everyone
much easier.

Perhaps you should look into it and propose to the FBSD team about
implementing something sane like this, hacking every driver to
add a new device ID is really a pain.

Cya


--

 // /
{:)==={ Darron Broad [EMAIL PROTECTED]
 \\ \ 

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


Re: Some mmap observations compared to Linux 2.6/OpenBSD

2003-10-22 Thread Bruce M Simpson
On Wed, Oct 22, 2003 at 09:40:44AM -0500, Dan Nelson wrote:
  The actual commit quote reads:
  
  use a red-black tree to find entries in the vm_map. augment the
  red-black tree to find free space between entries.  speeds up memory
  allocation, etc...
  
  I am wondering if there is a compelling reason why the technique used
  by OpenBSD could not be adapted to FreeBSD's VM system.
 
 Probably just a case of too much to do and not enough people to do
 it.  FreeBSD already has sys/tree.h, which provides the red-black tree
 macros.

Now accepting patches!

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


Re: sshd source code

2003-10-18 Thread Bruce M Simpson
On Fri, Oct 17, 2003 at 03:58:33PM -0700, Tim Kientzle wrote:
 Assuming, of course, that they don't ever
 turn their machine off.  If they do,
 then 'locate' is just a waste of disk space.

Or install the anacron port.

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


Re: Why is PCE not set in CR4?

2003-10-18 Thread Bruce M Simpson
On Wed, Oct 01, 2003 at 11:39:36AM +0200, Grumble wrote:
 I have read the perfmon documentation and source code. For several 
 reasons, I do not think it is totally adequate in my situation.
 
 It was designed in 1996 with the Pentium Pro in mind, which, 
 apparently, only has two performance counters:
 
   #define NPMC 2
   if (pmc  0 || pmc = NPMC) return EINVAL;
[..]
 Assume I get perfmon to work with my K7's 4 performance-monitoring 
 counters. Since PCE is not set, I am not allowed to call RDPMC from 
 ring 3. I have to make a system call, just to read the counters.

I've since read over perfmon and some notes on using performance monitoring
counters in The Indispensable PC Hardware Book.

It looks to me as though perfmon *will* do what you want. There isn't
really any need to reinvent the wheel. If you want to configure *all* your
PMCs to read particular events, then the best way to do this is as follows:

Conditionalise the PMC allocation code in perfmon.c to use a boot-time
tunable, or an int, which is set by the identcpu.c code. Allocate the PMC
structures in perfmon.c at boot-time (or preferably module init time).

Then, add the necessary code to perfmon_init() and a new writectlXX()
function pertaining to the particular Athlon you're using.

 I will pay in terms of computation overhead to process a system 
 call, instead of a single instruction. But more importantly, it will 
 wreck the cache, and possibly the TLB.
 
 There is no point in monitoring an event if the monitoring tools 
 disturb the environment too much.

Ignore the patch I sent previously. perfmon is i386 specific anyway, so
hacking perfmon.c is acceptable. What I would suggest instead is to add
two new ioctls to perfmon to do this.

 PMIOGPCE get pce bit value on current CPU
 PMIOSPCE set pce bit value on current CPU (if superuser)

This will allow you to set PMC enable on and off for the uniprocessor
case OK, and let you use RDPMC from ring 3. This is not valid for the
SMP case, however.

Unless you can achieve CPU binding (not affinity) with one of the current
scheduler(s) then reading the counters is likely to yield useless results
if your code spins across CPUs in an SMP system.

An IPI of some kind will be necessary if you want to tell all processors
to turn on their PCE bit at the same time. [EMAIL PROTECTED] is a good
guy to ask about this sort of thing.

I'd like to know how you're progressing with this.

BMS


pgp0.pgp
Description: PGP signature


Re: boot0 screen output with dual-boot of FreeBSD / WinXP

2003-10-17 Thread Bruce M Simpson
On Fri, Oct 17, 2003 at 01:25:04PM +0930, Daniel O'Connor wrote:
 Basically, no. There is no room left in boot0 :(
 
 I think you could do it by squeezing down some text strings, and removing 
 other [less common] entries though.

That's what I had to do when I special-cased it for serial console support.

If there's sufficient demand we could resurrect the 1024-byte boot0, but
call it something else.

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


Re: to write a device driver or not to write (i/o, opl3, stupidity)

2003-10-16 Thread Bruce M Simpson
  I mean, what services do drivers offer? What services they _need_ to offer? Do 
  they just create appropriate device nodes and let the applications to worry about 
  using them or do they do some data manipulation or do they offer routines and 
  interfaces for applications or what? What should this particular driver do as I 
  just want to read/write data.
  

I think for your application running in userland is fine, if kernel
programming is likely to be a steep learning curve. You can use nanosleep()
to get the timing you need.

On Wed, Oct 15, 2003 at 05:13:29PM -0400, Mathew Kanner wrote:
   I'm not positive about this but I think that you can do it
 from usermode by opening /dev/io (as root) and the use inb, outb
 macros defined in cpufunc.h.

You can also use i386_get_ioperm() and i386_set_ioperm(). These change
the I/O port permission bitmap in the process's Task State Segment (TSS)
accordingly, so that you can issue IN/OUT instructions without segfaulting
in a similar way to opening /dev/io. The only trouble with /dev/io is that
it's an all-or-nothing approach (processes literally can write anywhere in
I/O space); better to ask for what you need than ask for everything, IMHO.

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


Re: afaapps port committed to FreeBSD

2003-10-13 Thread Bruce M Simpson
On Mon, Oct 13, 2003 at 05:20:31PM +0200, Helge Oldach wrote:
 I may sound ignorant, but what is wrong with the FreeBSD-native aaccli
 utility that can be downloaded from Adaptec (5400s_fbsd_cli_v10.zip)?
 I have been using this for some time now with success.
 
 May I suggest to make a port out of this as well?

Already did. Didn't realize til after scottl@ told me the next day.

Check [EMAIL PROTECTED] :-)

BMS


pgp0.pgp
Description: PGP signature


Re: Determining CPU features / cache organization from userland

2003-10-13 Thread Bruce M Simpson
All,

Here are detailed design documents for determining cache and TLB
geometry across our currently supported processor architectures,
with recommendations outlined for implementation.

What I haven't addressed yet is how indirect consumers of the API might
use it, e.g. mutex consumers vs. UMA, in the context of allocating
cache-aligned mutexes from a mutex pool.

Please let me know your thoughts.

BMS

Detailed design for cache/tlb geometry discovery


all
---
Review NetBSD's uvm_page_recolor() viz applicability to FreeBSD VM/UMA.

alpha
-
Action: Add code to machdep.c in identifycpu() to fill out hw_cacheinfo.

Cache discovery: Static tables keyed on specific CPU model.
TLB discovery: Static tables keyed on specific CPU model.

Cache heuristic:
 8Kb L1 Split Direct Mapped (21064)
 2MB L2 Unified Direct Mapped (21064)
 All CPUs below 21264 have a 32-byte L1 line size.
 21264 (EV6) has a 64-byte L1 line size.
 Optional L3 cache.
TLB heuristic:
 ITLB 8KB page 8 lines, 4MB page 4 lines (21064)
 DTLB 32 lines, all page sizes, fully associative. (21064)

ia64

Action: Add code to machdep.c in identifycpu() to fill out hw_cacheinfo.
Review Linux's pal.h and palinfo.c. files.

Cache discovery: Call the platform functions PAL_CACHE_SUMMARY and
 PAL_CACHE_INFO to get this information.
TLB discovery: Static tables keyed on specific CPU model.

Cache heuristic:
 L1 typically split 4-way set-associative 16KB,
 L2 256KB unified, L3 3MB-6MB unified.
 Line size isn't defined by the architecture.
TLB heuristic:
 L1 TLB, split, data/instruction 32 entries each, fully associative
 L2 TLB, split, data/instruction 128 entries each, fully associative

i386 pc98 amd64
---
Action: Add code to identcpu.c to fill out hw_cacheinfo.

Cache discovery: Extended CPUID.
 Static tables if 486-class machine. No cache on 386.
TLB discovery: Extended CPUID.
 Static tables if 486-class machine. No cache on 386.

Cache heuristic (Intel): L1: 4-way, 32 bytes/line
Cache heuristic (AMD): L2: 8-way, 64 bytes/line
TLB heuristic (Intel):
 4KB Code: 32 entries, 4-way, LRU
 4MB Code: 2 entries, Fully associative, LRU
 4KB Data: 64 entries, 4-way, LRU
 4MB Data: 8 entries, 4-way, LRU
TLB heuristic (AMD):
 4KB L1 Code: 16 entries, Fully associative, LRU
 4MB/2MB L1 Code: 8 entries, Fully associative, LRU
 4KB L1 Data: 24/32 entries, Fully associative, LRU
 4MB/2MB L1 Data: 8 entries, 4-way, LRU
 4KB L2 Code: 256 entries, 4-way, LRU
 4KB L2 Data: 256 entries, 4-way, LRU

(That's 6 distinct TLBs to deal with on AMD-based i386 architectures).

powerpc
---
Action: Adapt from NetBSD as appropriate.

Cache discovery:
 Open Firmware on CHRP if available.
 Static tables keyed on specific CPU model.
TLB discovery:
 Open Firmware on CHRP if available.
 Static tables keyed on specific CPU model.

Cache heuristic:
  L1 line size: 32 bytes across family.
   Pre-G5: 32KB/32KB Split, 8-way
   G5: 64KB/32KB Split, 1-way
  L2 line size: 32/64/128 bytes,
TLB heuristic:
 PPC 601e:
  4KB Instruction TLB, 4 entries, most recently used translations
  UTLB, 256 entries, 2-way set associative, software selectable block size

OFW properties:
 i-cache-size i-cache-sets i-cache-block-size
 d-cache-size d-cache-sets d-cache-block-size
 tlb-size tlb-sets l2-cache

[*] CHRP only

mips

Action: Adapt from NetBSD as appropriate.

Cache discovery: Static tables keyed on specific CPU model.
TLB discovery: MIPS32/MIPS64 Privileged Resource Architecture registers
Cache heuristic: Split/unified L1/L2, unified L3.
TLB heuristic: 16KB page size, 64 entries, fully associative (R1)

sparc64
---
Action:
 Adapt existing code in cache.c to fill out and use hw_cacheinfo.
 Review assembly code, particularly that which abuses the TLB.
 Work closely with jake@ to avoid code churn.

Cache discovery: Open Firmware.
TLB discovery: Open Firmware.
Cache heuristic: Split L1, Unified L2.
TLB heuristic: Split L1 TLB. Fully Associative. NLU. 64 lines each.

OFW properties:
icache-size icache-line-size icache-associativity
dcache-size dcache-line-size dcache-associativity
ecache-size ecache-line-size ecache-associativity
#dtlb-entries #itlb-entries

Maintain information about cache and TLB geometry in an MI structure.
The abstraction is intended to reflect current and future machine
architectures.

It is expected that the contents of these structures may not change over
the lifetime of the kernel. Keeping this information in a structure doesn't
significantly increase the cost of retrieving it from userland anyway.

Userland consumers such as thread libraries and memory allocators should
take a copy of this structure upon initialization. Kernel consumers
may feel free to cache the information in local variables as they like.

TLBs are 'caches' for virtual address lookups. Like data and instruction
caches, they may employ set associativity to reduce the risk of
unnecessary cache flushes/misses in multiprogramming 

Re: Determining CPU features / cache organization from userland

2003-10-12 Thread Bruce M Simpson
All,

I came up with the attached text file today to summarize some of my
findings, after looking at various open source trees to see how they
handle run-time cache geometry detection.

Many will find it ironic that i386 is the easiest platform to deal with.

[ Andrew: Perhaps you can shed some light on how the necessary information
can be gathered on Alpha? My search was incomplete and I could not find
a reliable source for DEC's development manuals. ]

Jeff Roberson suggested I adopt NetBSD's API, however, on further
examination it's clear that NetBSD's approach isn't consistent across
all platforms. Darwin takes a similar approach, but it is perhaps too
PowerPC-centric.

sysctl is a good interface for retrieving this information as it doesn't
change during the lifetime of the kernel, and it is small. sysctl is already
invoked from within libc to retrieve information in this way.

glibc's approach to dealing with situations where knowledge of the cache
line size is needed is a bit fractious - it retrieves the information from
an 'aux vector' passed to glibc at startup.

I think threading libraries should seriously consider becoming consumers of
the API once it's finalized. Mutex alignment on cache line boundaries is
desirable for userland applications too. However, phk malloc would need to
be changed in order to support this specific form of aligned allocation.

Perhaps a separate pool or zone could be used for this kind of allocation?
This becomes more important and timely when one considers the I/O alignment
restrictions we've encountered. Some applications may need to align their
buffers on arbitrary boundaries to suit devices, too.

BMS

all
---
NetBSD cache information API(s) are not consistent across platforms.

alpha
-
Cache discovery? Static.
21064, 21064A, 21066, 21066A, 21164 all have line sizes of 32-bytes.
The 21264 has a 64-byte line size.
21364: L1 split, 64KB each, 2-way set-associative, 
Virtual caches can be implemented using PALcode, but this is
probably more of a curiosity than anything else.

ia64

Cache discovery? Call PAL_CACHE_INFO, I think.
No documentation on how to do this at this time.
I have emailed [EMAIL PROTECTED] asking for advice.

i386 pc98 amd64
---
Cache discovery? CPUID.
Earlier chips which don't support it probably don't have a cache,
or aren't worth supporting.

General rule for x86: split L1, unified L2, optional unified L3.
General rule for Intel P5: 2-way, 32 bytes/line
General rule for Intel MMX and up: 4-way, 32 bytes/line
PPro doesn't have L3.
The newer cores have different cache geometry.

powerpc
---
Cache line discovery? Static.
Many core variants.
I have not seen any runtime code for this.
The POWER clcs instruction is obsolete.

OpenDarwin assumes 32-bytes. It has hooks for discovering the
cache geometry at runtime but these are not used.

NetBSD statically initializes this information according to the
discovered CPU model in use, which is the way to go.
NetBSD tells uvm to recolor the page queues if required.

Linux uses static #define's from IBM people, except in the case
of ppc64, which is strikingly similar to the OpenDarwin code
except it actually talks to the open firmware.

Open Firmware on CHRP should however provide the following
for each cpu device node configured in the system:
i-cache-size i-cache-sets i-cache-block-size
d-cache-size d-cache-sets d-cache-block-size
tlb-size tlb-sets l2-cache
All are integers except for l2-cache which is the address of an l2-cache
device node if the system found one.

mips

The NetBSD MIPS code for dealing with cache geometry
was recently updated.
MIPS caches may be split/unified at L1/L2 and unified at L3.
Cache detection code is quite voluminous. Swipe NetBSD's
if FreeBSD/mips ever kicks off.
Many, many core variants.

sparc64
---
Cache line discovery? Performed by Open Firmware.

Open Firmware property names used are ever so slightly different from Apple's.
icache-size icache-line-size icache-associativity
dcache-size dcache-line-size dcache-associativity
ecache-size ecache-line-size ecache-associativity

Already handled within cache.c, but assembly stubs *expect* this
information in a certain format.  Specifically they need to see
the data cache/instruction cache sizes and line sizes.

General rule: Split L1, Unified L2.
Cores: Spitfire/Blackbird/Cheetah
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Dynamic reads without locking.

2003-10-11 Thread Bruce M Simpson
On Fri, Oct 10, 2003 at 10:31:21PM -0700, Tim Kientzle wrote:
 On further inspection, I'm pretty sure that sys/kern/subr_devstat.c
 is not correct.

OK. What about the shared page interface? Specifically the comment
above devstat_end_transaction(). The generation count is used by
the old sysctl interface. The shared page interface has a liberal
sprinkling of atomic*() instructions.

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


Re: Determining CPU features / cache organization from userland

2003-10-11 Thread Bruce M Simpson
On Sat, Oct 11, 2003 at 01:58:27PM +1000, Peter Jeremy wrote:
 If you do this,  it may make sense to use the same names as MacOSX.
 
 What if your hardware has different linesizes for different caches?

I noticed whilst peering in Apple Developer Notes that G5 has 128 byte
cache line size, and this screws up mutexes bigtime. (!!)

OS X definitions considered too PowerPC centric. I think the best way
to handle all cases is thus:-

 - Support 3 levels of cache.
 - Each level may be unified or split between code and data
   not-quite-Von-Neumann-style.
 - Allow explicit retrieval of this info keyed on the cache you're
   interested in. This means: hw.cache.lN.(linesize|lines|sets)
 - Do similar for the TLB insofar as we can return information about
   the chip's TLB. I know for example from talking to peter@ that
   the Opteron is quite a different beast (ASNs, flush filter, etc).
 - Assume that all CPUs have identical characteristics in an SMP system.
   Trying to assume otherwise is pointless. People should be using matched
   chips anyway.

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


Re: smallest piece of hardware that runs *BSD?

2003-10-11 Thread Bruce M Simpson
On Fri, Oct 10, 2003 at 07:37:23PM -0700, Wes Peters wrote:
 Grab a copy of Embedded Systems Programming, there are ads for things like 
 this all over near the back of the magazine.  In particular, the chip in 
 whatever USB stick you're looking at probably has an 8-bit CPU of some 
 sort in it.

I find Circuit Cellar is also a good periodical for stuff like this!

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


  1   2   >