SIOCADDMULTI doesn't work, proposed fix
After experimenting some more, I've come to the conclusion that trying to
manually add a non-IP ethernet multicast address doesn't work properly.
The ether_resolvemulti() assumes that addresses will be specified as
either AF_LINK or AF_INET; if the family is AF_LINK, it assumes that
a struct sockaddr_dl will be used. However, the user is supposed to
pass the address using a struct ifreq, and struct ifreq uses struct
sockaddr, not struct sockaddr_dl.
The original code in 2.2.x expected a struct sockaddr with a family
of AF_UNSPEC. This no longer works in 3.0, which breaks compatibility.
Among other things, the Columbia Appletalk port doesn't work because
of this.
As an aside, the equal() macro in /sys/net/if.c does a bcmp() using
sa_len as the length of the data to check, but doesn't account for
the possibility of sa_len being 0 (this makes it always return true,
which can yield false positives).
The patches included with this post change /sys/net/if.c and
/sys/net/if_ethersubr.c so that adding a mutlicast address with
SIOCADDMULTI using a struct sockaddr and AF_UNSPEC works again. I would
like Those Who Know More Than I (tm) to review these changes and offer
criticisms and comments.
These patches are against 3.0-RELEASE but should apply to -current
and -stable as well.
-Bill
--
=
-Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu
Work: wp...@ctr.columbia.edu | Center for Telecommunications Research
Home: wp...@skynet.ctr.columbia.edu | Columbia University, New York City
=
It is not I who am crazy; it is I who am mad! - Ren Hoek, Space Madness
=
*** if.c.orig Sun Jan 31 17:13:01 1999
--- if.cSun Jan 31 17:10:36 1999
***
*** 186,192
register struct ifaddr *ifa;
#define equal(a1, a2) \
! (bcmp((caddr_t)(a1), (caddr_t)(a2), ((struct sockaddr *)(a1))-sa_len) == 0)
for (ifp = ifnet.tqh_first; ifp; ifp = ifp-if_link.tqe_next)
for (ifa = ifp-if_addrhead.tqh_first; ifa;
ifa = ifa-ifa_link.tqe_next) {
--- 186,193
register struct ifaddr *ifa;
#define equal(a1, a2) \
! (((struct sockaddr *)(a1))-sa_len \
!bcmp((caddr_t)(a1), (caddr_t)(a2), ((struct sockaddr *)(a1))-sa_len) == 0)
for (ifp = ifnet.tqh_first; ifp; ifp = ifp-if_link.tqe_next)
for (ifa = ifp-if_addrhead.tqh_first; ifa;
ifa = ifa-ifa_link.tqe_next) {
***
*** 636,642
return EOPNOTSUPP;
/* Don't let users screw up protocols' entries. */
! if (ifr-ifr_addr.sa_family != AF_LINK)
return EINVAL;
if (cmd == SIOCADDMULTI) {
--- 637,644
return EOPNOTSUPP;
/* Don't let users screw up protocols' entries. */
! if (ifr-ifr_addr.sa_family != AF_LINK
! ifr-ifr_addr.sa_family != AF_UNSPEC)
return EINVAL;
if (cmd == SIOCADDMULTI) {
*** if_ethersubr.c.orig Sun Jan 31 17:13:07 1999
--- if_ethersubr.c Sun Jan 31 17:00:54 1999
***
*** 778,783
--- 778,800
u_char *e_addr;
switch(sa-sa_family) {
+ case AF_UNSPEC:
+ e_addr = (u_char *)sa-sa_data;
+ if ((e_addr[0] 1) != 1)
+ return EADDRNOTAVAIL;
+ MALLOC(sdl, struct sockaddr_dl *, sizeof *sdl, M_IFMADDR,
+ M_WAITOK);
+ sdl-sdl_len = sizeof *sdl;
+ sdl-sdl_family = AF_LINK;
+ sdl-sdl_index = ifp-if_index;
+ sdl-sdl_type = IFT_ETHER;
+ sdl-sdl_nlen = 0;
+ sdl-sdl_alen = ETHER_ADDR_LEN;
+ sdl-sdl_slen = 0;
+ e_addr = LLADDR(sdl);
+ bcopy((char *)sa-sa_data, (char *)e_addr, ETHER_ADDR_LEN);
+ *llsa = (struct sockaddr *)sdl;
+ return 0;
case AF_LINK:
/*
* No mapping needed. Just check that it's a valid MC address.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: SIOCADDMULTI doesn't work, proposed fix
Of all the gin joints in all the towns in all the world, Garrett Wollman had to walk into mine and say: On Sun, 31 Jan 1999 17:55:22 -0500 (EST), Bill Paul wp...@skynet.ctr.columbia.edu said: a struct sockaddr_dl will be used. However, the user is supposed to pass the address using a struct ifreq, and struct ifreq uses struct sockaddr, not struct sockaddr_dl. This is called ``poor man's inheritance''. I believe it is an error for any code to use AF_UNSPEC for any purpose other than masks (where it makes sense since the address family is normally not included in the mask). A `sockaddr_dl', while by default longer than a `sockaddr', in this case will fit withing the structure allotted. In the future, I fully expect that `sockaddr' will be of maximal length (we need this for IPv6). There's still one small problem: the code as it stands now can return success and still not update the multicast filter. If you pass a structure with AF_LINK as the family but with the length set to 0, if_addmulti() falsely detects that the entry already matches an existing one and returns success (it the equal() macro equates to a bcmp(), which tries to compare 0 bytes worth of data and returns success). In my opinion, this is a bug: either the equal() macro should return false, or the zero length field should be detected by a sanity check and the function should return EINVAL. The patches included with this post change /sys/net/if.c and /sys/net/if_ethersubr.c so that adding a mutlicast address with SIOCADDMULTI using a struct sockaddr and AF_UNSPEC works again. I would like Those Who Know More Than I (tm) to review these changes and offer criticisms and comments. There are two things which should be done here. First, the kernel AppleTalk code should be fixed to join the necessary multicast groups when an interface is first configured for AppleTalk. (By preference the AARP implementation should be entirely in the kernel as well, but that's more of a challenge.) Second, the generic ether_resolvemulti function should be enhanced to know about AppleTalk multicast addresses. The Columbia Appletalk code is not the same as netatalk: it's implemented entirely in user space and uses BPF as well as manually joining multicast groups. The existing Columbia Appletalk port, which works on 2.2.x, uses SIOCADDMULTI with a family of AF_UNSPEC. I rifled through a bunch of man pages in 3.0-RELEASE trying to find the Right Way To Do This (tm) but came up empty. If the right way to do this is to cast the struct sockaddr to a struct sockaddr_dl and use AF_LINK, then this should be documented somewhere. (If it is documented and I missed it, feel free to slap me around and point me in the right direction.) -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | Columbia University, New York City = It is not I who am crazy; it is I who am mad! - Ren Hoek, Space Madness = To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
CAP port and non-IP multicast
Somebody wrote me recently to tell me they were having trouble getting the Columbia Appletalk package to work with a PCI ethernet card. Looking through both the Columbia Appletalk code and the kernel, I think the problem is a general one not necessarily related to a given ethernet driver. I'm not sure what the proper fix is though. The CAP code contains a module called cap60/support/ethertalk/bpfiltp.c which contains library support code for libcap when the package is built with EtherTalk Phase 2 support. As the name implies, it works with BPF, but it also contains the pi_addmulti() routine. The aarpd program uses this function to join the 09:00:07:ff:ff:ff multicast group. Since this is not an IP multicast group, you have to specify something besides AF_INET as the family when using SIOCADDMULTI to join. The question is, what should this something else be. In 2.2.x, you have to use AF_UNSPEC, but in 3.x and up, you have to use AF_LINK. The CAP port uses AF_UNSPEC in both cases, which is incorrect if you're building the port on a 3.0 (or 4.0) host. What's the right way to fix this? There are really two possibilities: 1) change bpfiltp.c so that it conditionally uses AF_UNSPEC or AF_LINK depending on the OS release on which the port is being compiled, or 2) change sys/net/if_ethersubr.c so that it treats AF_UNSPEC and AF_LINK the same. I expect changing the CAP code would be the more 'politically correct' approach, but it doesn't seem unreasonable to allow backwards compatibility in the kernel code either. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | Columbia University, New York City = It is not I who am crazy; it is I who am mad! - Ren Hoek, Space Madness = To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: btokup().. patch to STYLE(9) (fwd)
-Original Message-
From: Doug Rabson [mailto:d...@nlsystems.com]
Sent: 29 January 1999 10:49
To: Sheldon Hearn
Cc: Greg Lehey; curr...@freebsd.org
Subject: Re: btokup().. patch to STYLE(9) (fwd)
On Fri, 29 Jan 1999, Sheldon Hearn wrote:
On Fri, 29 Jan 1999 20:01:23 +1030, Greg Lehey wrote:
...
Documentation is the castor oil of programming.
Managers know it
must be good because the programmers hate it so much.
I take this to mean provide above your expression a comment that
explains what you're doing, not clutter your expression with
unnecessary parens in case you've made a mistake that
nobody will spot
because you haven't commented your code properly.
The reason I'm interested in this (now tiresome) thread is
that I'd much
rather have to read
/*
* Bail out if the time left to next transaction is less than
* the duration of the previous transaction.
*/
if (t % u - n % u d % u) {
than
if (((t % u) - (n % u)) (d % u)) {
This is a strawman. The original expression is perfectly fine (by my
rules). One could make a case for:
if ((t % u) - (n % u) d % u)
You could just as easily make a case for
if ((t % u - n % u) (d % u))
the parens then draw your eye naturally to the central operator but
anyhow
I think this sums up the general problem with style(9) and also this
thread. The style guide does not say anything definitive about how to
parenthesize the above expression. What style(9) says, and it's been
quoted many times already is
Don't use parentheses unless they're required for precedence or the
statement is really confusing without them.
^^^
Not this second bit, style(9) *ALLOWS* the use of extra parentheses when
the programmer feels the statement would be really confusing without
them. The whole argument is over what people consider to be really
confusing and that is definately something down to the person doing the
coding.
In my mind, adding extra parens for readibility is a good thing and I
fail to see where my opinion is in any way in conflict with style(9)
since I only add them if I feel that the expression would be more
confusing without them. I think people reading the above quote from
style(9) and interpreting it as meaning we should be minimalist in our
use of parens is misreading it.
To be honest, style(9) as it stands is worthless since it has paragraphs
such as the following in it
In general code can be considered ``new code'' when it makes up about
50% or more of the files[s] involved. This is enough to break precedents
in the existing code and use the current style guidelines
Over time this can only lead to a mishmash of styles throughout the
codebase. I disagree with this being acceptable practice, it's a cop-out
which basically says, we have a style guide that encapsulates how the
current code looks but you're free to write in any style you want as
long as you write enough of it. In the long run you may as well not
bother with style(9), either there is a standard style or there isn't, a
man page documenting current style without advocating continuing
adherence is a rather pointless exercise.
It think it's a mistake to allow programmers to veer away from a common
style. Without consistency across the project it becomes difficult to
maintain code, which is why KNF exists in the first place.
Paul.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
RE: btokup().. patch to STYLE(9) (fwd)
-Original Message- From: Julian Elischer [mailto:jul...@whistle.com] Sent: 29 January 1999 17:48 To: Warner Losh Cc: Andrew Kenneth Milton; curr...@freebsd.org Subject: Re: btokup().. patch to STYLE(9) (fwd) On Fri, 29 Jan 1999, Warner Losh wrote: if ((a 0) (b 0)) Personally while I KNOW (after wasting a second thinking about it) that the example below is the same as that above, I ALWAYS code as above. It takes me about 1/5th the time to know what it means. if (a 0 b 0) If I were working on this code written by someone else it'd leave my editor looking like the top example, that's for sure. I think that How easy is it to edit a piece of code and still have it do what you expect is an important consideration, because people DO edit things. I do agree that complex things like: if (a | b c % d ^ e) should really have some parents to show what is going on. I have NO idea of what that is doing and I have plans of looking it up in the book to work it out.. The interesting thing about this example, and there's probably something in this, is that the first example is trivial to understand without parens because it parses left to right as an English expression i.e. if (a 0 b 0) if a is less than 0 and b is less than 0 It mirrors the way we read spoken language so it's very quick to see what's going on. With the more difficult expression if (a | b c % d ^ e) there's no spoken language analogy that flows left to right so we have to parse it in much the same way as the compiler does. I bet that most people are mentally putting braces around the expressions to break it up or at least something along those lines. Therefore it makes sense to actually put the parens there in the first place so that people can parse it more quickly with the naked eye. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Network/ARP problem? Maybe pn driver?
Of all the gin joints in all the towns in all the world, Christopher
Masto had to walk into mine and say:
On Fri, Jan 29, 1999 at 02:52:07PM -0800, Bill Fenner wrote:
Can you run a tcpdump arp on the machine that is having the problem,
as well? This could help to determine if it's a driver problem (e.g.
if the replies don't show up) or an ARP problem (e.g. if the replies
do show up but arp doesn't use them).
Good idea.
Hmm. Running tcpdump seems to make the problem go away. The ARP
replies show up immediately appear in the table. Clue.
You should have tried that first.
There's something I'd like you to try for me. (Don't delay in trying
this; I've had a long string of people who appear suddenly, complain
about a problem of some sort, then vanish before I can extract enough
information from them to find a solution.)
I was menaced by a bug in the PNIC's receive DMA operation which, according
to all my tests, only appeared in promiscuous mode. I devised a workaround,
however it's only enabled when the IFF_PROMISC flag is set on the
interface. Running tcpdump (without the -p flag) places the interface
in promiscuous mode and enables the workaround. Given what you've said,
it's possible that we need to enable the workaround all the time, not
just in promiscuous mode.
Do me the following:
- Bring up /sys/pci/if_pn.c in your favorite editor.
- Locate the pn_rxeof() function and find the following code:
#ifdef PN_PROMISC_BUG_WAR
/*
* XXX The PNIC seems to have a bug that manifests
* when the promiscuous mode bit is set: we have to
* watch for it and work around it.
*/
if (sc-pn_promisc_war ifp-if_flags IFF_PROMISC) {
[...]
- Change the if() clause so that it looks like this:
if (sc-pn_promisc_war /* ifp-if_flags IFF_PROMISC*/) {
(In other words, comment out the test for the IFF_PROMISC flag.)
This will enable the workaround all the time and allow the receiver bug
to be detected and handled properly.
Compile a new kernel with this change and see if the problem persists.
Report back your findings (one way or the other) so that I'll know if
I should modify the code in the repository.
-Bill
--
=
-Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu
Work: wp...@ctr.columbia.edu | Center for Telecommunications Research
Home: wp...@skynet.ctr.columbia.edu | Columbia University, New York City
=
It is not I who am crazy; it is I who am mad! - Ren Hoek, Space Madness
=
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
RE: DEVFS, the time has come...
-Original Message- From: Poul-Henning Kamp [mailto:p...@critter.freebsd.dk] Sent: Tuesday, January 26, 1999 10:41 AM To: Doug Rabson Cc: Archie Cobbs; Maxim Sobolev; curr...@freebsd.org; Julian Elischer Subject: Re: DEVFS, the time has come... No, it doesn't have to be SLICE. In particular, if we're going the SLICE way, it should be done right, and Julians SLICE code didn't do that. (I know, I spent close to 6 months prototyping the concept and julian had my code to work from). Wouldn't it be possible to fit this into the device system? If we treat disks as devices and partition types as drivers, most of the boring work of matching drivers to devices and keeping lists and trees of objects will happen automatically. Well, as long as you remember that it is not a strict hierarchy: I could slice two disks, mirror the slices and concatenate the mirrors if I wanted to. Where does this happen though? If we go with Doug's idea (which seems quite neat), then the device subsystem will present devices for each of the slices/partitions that the low level disk handling code finds during the probe phase. The mirroring of slices and subsequent concatenation of the mirrors, or any other combination of slice munging that might take place happens later doesn't it, using something like vinum. If so then can't vinum become responsible for modifying the device view, i.e. if it creates a concatenated partition then it could remove the two low level slice devices and create a new disk device that represents the concatenated area. You might not want to remove the low level devices or it could be a vinum configuration option. If something like vinum doesn't exist then you're not going to be doing any mirroring or concatenation and Doug's solution would be fine for creating the device nodes needed to represent the actual layout of the disks, as opposed to a view of the disks that might be created by vinum et al. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: 4.0-Current, netscape halts system
-Original Message- From: Reginald S. Perry [mailto:pe...@zso.dec.com] Sent: Tuesday, January 26, 1999 7:35 AM To: Jeroen Ruigrok/Asmodai Cc: Andrew Gordon; curr...@freebsd.org; Matthew Dillon Subject: Re: 4.0-Current, netscape halts system I have been having these X lockups with the linux netscape 4.5 running. I may have exacerbated it when I installed the linux realplayer and macromedia flash plugins. I would like to have a methodology to help debug this, but I have just this one system to use as the debug system. I do also have a vt220 which I could set up if that would help. The key here is that for me it locks the system up completely. I cannot telnet in remotely and the ctrl-alt-esc key sequence does not work so its unclear to me how to debug this. Tell me what I would need to help debug it, and I will try to be of some help. Ill attach my dmesg output. I've had the problem recently and in the past where the system locks up completely and a lot of the time the speaker starts a continuous beep. Locks up solid, requires a power-cycle. It's not a new problem, it used to happen a lot on my dual processor box and I've had it happen a few time this week on my single processor dev box. The hardware is very different on both boxes and compared to yours so the cause must be somewhere fairly generic. I *think* Netscape was in use every time but I can't see how netscape itself can be directly responsible for a system lockup, it must be tickling some interrupt problem. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: WARNING: Today's current breaks passwords
-Original Message- From: Sheldon Hearn [mailto:a...@iafrica.com] Sent: Friday, January 22, 1999 3:17 PM To: Maxim Sobolev Cc: curr...@freebsd.org Subject: Re: WARNING: Today's current breaks passwords On Fri, 22 Jan 1999 16:51:40 +0200, Maxim Sobolev wrote: Maybe your have switched between hashing modes (DES-MD5 or MD5-DES)? Possibly that's what's happened, but it certainly isn't something I did deliberately. It happened to me too. Did a cvsupdate after the tag and Matt's code was commited, did a make world, built a new kernel, rebooted and couldn't log in! After changing root's password it went from being DES to SHA1 so I suspect it's failing to honour the existing hash algorithm and trying to use SHA1 regardless. Brandon looks like he's been around here recently, like yesterday when it happened :-). Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: keymaps
-Original Message- From: John Fieber [mailto:jfie...@indiana.edu] Sent: Friday, January 22, 1999 3:51 PM To: Kazutaka YOKOTA Cc: curr...@freebsd.org Subject: Re: keymaps On Fri, 22 Jan 1999, Kazutaka YOKOTA wrote: Gentlemen, I don't intend to add yet another keymap to /usr/share/syscons/keymaps. I am merely trying to define a reasonable set of common, consistent key binding for existing keymaps. National keyboards have different layout of regular keys. But function keys and special keys are placed identically. They should work in the same way, or at least similar way in all keyboards, unless there is a good reason to do otherwise. (I am not talking about non-AT keyboards which are totally different from either AT 84 or 101/102/104 keyboards.) What would be useful here is the ability to compose keymaps. There would be basically two sets: one that defines the layout of the main keyboard and one that defines the layout of the other keys. That way I could pick my dvorak layout, then add on a layout that, say, swaps control and caps lock but leaves the main layout alone. I was thinking something similar, a way to dynamically modify the map ala xmodmap would be useful so that users who have particular preferences can implement the changes in, say, .login That's exactly what I do with xmodmap and X. The standard maps can continue to reflect the actual layout of the keyboards then rather than having a number of variations according to popular user preference. Paul To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: KLD naming
-Original Message- From: Julian Elischer [mailto:jul...@whistle.com] Sent: Thursday, January 21, 1999 7:58 AM To: Mike Smith Cc: Christian Kuhtz; David O'Brien; curr...@freebsd.org Subject: Re: KLD naming well you're about to get your first test we are releasing the netgrpah code in full production form tonigh (if the version we've put together for release passes all tests tonight) The whole thing installs as KLD modules (or linked in of course) our present names are all predicated with ng_ hence ng_socket ng_rfc1490, ng_frame_relay etc the base module is 'netgraph'. now what would you suggest? we can still cahnge it before we release and no-body knows any better but after is always harder to change than beefore.. Why not have a third party identifier on the front, e.g. whistle_ng_rfc1490 You can determine your own naming scheme then and if we make this standard then it will ensure that third party supplied modules don't result in name space conflicts. It's perfectly feasible in the future that different companies might produce competing modules for subsystems, sound for example, so we might as well deal with this possibility now. Makes it easier to identify the source of the modules as well. Perhaps we should adopt a FreeBSD prefix on core modules so you can see from ls what's part of the OS and what's been added in from elsewhere. Although I'm in favour of this naming scheme over directories you can reach the point where the names are holding too much metainformation that really should be directory structure. There wouldn't be need for directories at all if you put the structure in the filename :-) Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: KLD naming
-Original Message- From: Julian Elischer [mailto:jul...@whistle.com] Sent: Thursday, January 21, 1999 5:39 PM To: p...@originative.co.uk Cc: m...@smith.net.au; c...@adsu.bellsouth.com; obr...@nuxi.com; curr...@freebsd.org Subject: RE: KLD naming Well whistle is giving htis away so we don'tthink it should be whistle_xxx any more than the kernel should be UCB/... It occur to me that eventually every single device driver will be a KLD an also a lot of other things besides... there are going to be a LOT of files in /modules Ok, in this case maybe it doesn't apply but in general we should determine what the guidelines for third party module developers should be to avoid namespace clashes. I though a FreeBSD prefix for modules shipped as part of FreeBSD would be useful to list all those modules that are *not* third party supplied when you've got a directory full of the things. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: KLD naming
-Original Message- From: Mike Smith [mailto:m...@smith.net.au] Sent: Thursday, January 21, 1999 8:25 PM To: p...@originative.co.uk Cc: curr...@freebsd.org Subject: Re: KLD naming ... Ah, understood. I'd be inclined to use a suffix, so that our prefix-based classification scheme still worked, eg. dev_ahc_Adaptec.ko kern_descrypt_RSA.ko etc. Hmm, wouldn't this impose our kernel structure onto modules? This might not be desirable for external developers, they may just want to provide a single module rather than split the product into submodules that fit our categories. Why not allow SafeCo_firewall.ko rather than netif_foo_SafeCo.ko netproto_bar_SafeCo.ko etc. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: Directory structure on current.freebsd.org
-Original Message- From: Peter Jeremy [mailto:peter.jer...@auss2.alcatel.com.au] Sent: Wednesday, January 20, 1999 6:21 AM To: freebsd-current@FreeBSD.ORG Subject: Re: Directory structure on current.freebsd.org Oliver Fromme o...@dorifer.heim3.tu-clausthal.de wrote: In releases/snapshots they're called axp and x86, while in ports they're called alpha and i386. I agree that having two different names is confusing. DEC (or Compaq) literature seems to use both Alpha and AXP - I'm not sure that either is an especially better choice. x86 could imply that we're running on 286, too, and it's more in line with sparc64), I personally find i386 a pain because it is used to specify both an architecture (IA-32) and a particular implementation (80386) of that architecture. In some cases it may not be clear which is meant. I think the architecture names are more appropriate than any cpu related name. For the alpha, while we might all use alpha in everyday speech axp is more specific when it comes to releases since the alpha release of the alpha code can get a tad confusing, I think that's why it was changed in the first place. It'd be nice if i386 could become IA32 but it probably won't happen. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: KLD naming
-Original Message- From: Archie Cobbs [mailto:arc...@whistle.com] Sent: Wednesday, January 20, 1999 6:13 AM To: d...@nlsystems.com Cc: gelde...@mediaport.org; curr...@freebsd.org Subject: Re: KLD naming Doug Rabson writes: Might it be a good idea to choose a consistent naming scheme for the modules? I'd think so because it would help blind loading at the boot prompt. If you choose names it the following format: type_name saver_warp saver_daemon the modules of one type will sort together in a directory listing. This is a change that will make FreeBSD more user friendly I think. When I first started writing KLD, I had a vague notion that there would be a simple directory structure under /modules, e.g.: /modules pci/ ncr.ko ... isa/ if_ed.ko ... ... I like this idea (subdirectories) better.. it will last longer :-) Witness the explosion of the ports tree. You should then be able to load a module isa/if_ed.ko etc and have it work (no leading slash). I don't think subdirectories based on bus type is a good idea, it doesn't really fit the granularity we're probably heading towards. Some thinks don't really fit at all, filesystems, screen savers etc and even for drivers we're heading towards less bus specific devices so an ethernet driver, say, would be the same for any bus, only the startup code would be different and possibly(probably) in a different module. A functional structure is probably better /modules /devices /ethernet /storage /display /network /filesystems /screensavers etc. Not a specific proposal for actual directories but perhaps a better direction. I think we should start thinking more in terms of function, rather than bus, in a lot of what we do with devices as we abstract out the bus code more effectively. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
The removal of MT_RTABLE
The removal of MT_RTABLE by fenner in rev 1.32 of /sys/sys/mbuf.h has broken the build of the tree in netstat. It may have broken other net apps that I haven't hit yet. There's also a new coding style that I've not come across before being used in this file, it's based on commenting out lines by clobbering the first two chars, e.g. /*efine MT_RTABLE 5*/ /* routing tables */ It looks like it was invented by Garret and fenner followed his good example :-) Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Looking for testers...
there are no errors, then I'd like to know that as well. :) Note: please don't ask me for a -stable version of this driver. I'm posting this to -current for a reason. If you're not running -current, then either set up a -current box or just sit back and enjoy the show. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: [EMAIL PROTECTED] | Center for Telecommunications Research Home: [EMAIL PROTECTED] | Columbia University, New York City = "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: FreeBSD Celeron and Celeron ( Mendocino ) kernel patch.
-Original Message- From: Garrett Wollman [mailto:woll...@khavrinen.lcs.mit.edu] Sent: Saturday, January 09, 1999 4:22 PM To: Kenneth Wayne Culver Cc: Garrett Wollman; Bryan Seitz; curr...@freebsd.org Subject: Re: FreeBSD Celeron and Celeron ( Mendocino ) kernel patch. On Sat, 9 Jan 1999 11:12:20 -0500 (EST), Kenneth Wayne Culver culv...@wam.umd.edu said: Well, they are the same in that respect, but the Pentium II has cache in the same package, and most Pentium II's aren't overclockable. The celeron is. That's OK -- we don't support overclocking anyway. The Celeron does have a cache in the package, BTW. The cache in the Celeron is this tiny little thing that is actually capable of running at clock rates of 250 MHz or higher; the actual CPU is a perfectly ordinary Pentium-II core of the sort that would be labeled as ``450 MHz'' when coupled with a more expensive cache. (According to my friend who does VLSI design.) The Celeron chips are intentionally down-rated by Intel marketing to keep them from cannibalizing the high-end market. (Remember when upgrading to a faster line printer meant that a SE would change a single belt?) I think we should stick to identifying the core. I disagree. From an user perspective I think it will be confusing to general users to report PII when they think they've got a Celeron. From a support perspective it might be useful to know what CPU is actually installed rather than just the class of CPU. On a related note, I'd be interested in benchmarks for the Celerons, how does the on-chip cache compare to the off-chip cache. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
gdb slain in drive-by commit, film at 11
Gdb has stopped working recently in -current. In a snapshot from
October 24th, it's fine. In a snapshot from November 15th (before
the great gcc switchover), it's hosed. I've been told it's hosed in
today's -current as well. Here are the symptoms:
tuba# uname -sr
FreeBSD 4.0-19991115-CURRENT
tuba# cat f.c
#include stdio.h
main()
{
printf("hello world\n");
}
tuba# cc -g f.c
tuba# gdb -q a.out
(gdb) run
Starting program: /tmp/a.out
warning: find_solib: Can't read pathname for load map: Bad address
Segmentation fault (core dumped)
tuba#
A statically compiled executable works though:
tuba# cc -static -g f.c
tuba# gdb -q a.out
(gdb) run
Starting program: /tmp/a.out
hello world
Program exited with code 014.
(gdb)
Okay, 'fess up: who's the wise guy.
-Bill
--
=====
-Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu
Work: [EMAIL PROTECTED] | Center for Telecommunications Research
Home: [EMAIL PROTECTED] | Columbia University, New York City
=
"It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness"
=
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
