Re: crash partition
On Sat, Mar 02, 2002 at 06:20:09PM -0800, Crist J. Clark wrote: > Make a separate swap partition for each since you are going to be > using the disk space anyway if you go with another setup. Hmmm... yes, suppose you're right. Thanks for directing me to the obvious. -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] my FreeBSD column: http://www.oreillynet.com/pub/q/Big_Scary_Daemons http://www.blackhelicopters.org/~mwlucas/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multicast problem with sis interface?
Hi, The padding thing is a red herring - sorry about that. The real problem seems to be the interface's filtering, because setting the interface promiscuous makes the problem go away. See kern/35511 for details and a workaround. I imagine the proper fix is a 2 minute job for someone who understands the chipset. -- Bob Bishop +44 (0)118 977 4017 [EMAIL PROTECTED]fax +44 (0)118 989 4254 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
A few questions about a few includes
Am I just completely stupid, or do we have a few things that could use a
little cleaning up in /usr/include as well as in the man page for kvm_*?
System: FreeBSD 4.5-STABLE
1) The man page for the kvm_* functions lists the following #include
dependencies:
#include
#include
#include
However, kvm.h contains some declarations that also require and
(namely, struct kinfo_proc and struct proc). Otherwise, one
might encounter warnings/errors re: incomplete types.
2) If compiling with the -pedantic switch, one might see something like
this:
In file included from main.c:151:
/usr/include/sys/proc.h:108: warning: ANSI C forbids zero-size array
`ar_args'
In :
/*
* pargs, used to hold a copy of the command line, if it had a sane
* length
*/
struct pargs {
u_int ar_ref; /* Reference count */
u_int ar_length; /* Length */
u_char ar_args[0]; /* Arguments */
};
This does indeed seem to make little or no sense. Could someone explain
this? Is ar_args supposed to be a pointer or what?
3) Furthermore, on including , one then sees this:
In file included from /usr/include/sys/user.h:40,
from main.c:153:
/usr/include/machine/pcb.h:90: warning: struct has no members
In :
/*
* The pcb is augmented with machine-dependent additional data for
* core dumps. For the i386: ???
*/
struct md_coredump {
};
Nowhere under /usr/include is a more complete definition of md_coredump to
be found. This looks awfully "kludgy" to me.
I do hope someone can shed some light here. Thanks.
--
Conrad Sabatier <[EMAIL PROTECTED]>
First Rule of History:
History doesn't repeat itself -- historians merely repeat each
other.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: A few questions about a few includes
>
> In :
>
> /*
> * pargs, used to hold a copy of the command line, if it had a sane
> * length
> */
> struct pargs {
> u_int ar_ref; /* Reference count */
> u_int ar_length; /* Length */
> u_char ar_args[0]; /* Arguments */
> };
>
> This does indeed seem to make little or no sense. Could someone explain
> this? Is ar_args supposed to be a pointer or what?
This is a common technique for defining a structure which is some
descriptive information about an array of objects is followed by an
open-ended array of those objects. (In this case the "objects" are
characters.) The ar_args member of the structure gives a name to that
location in the structure without reserving any space (and thus when the
technique is used, there can only ever be one [0] member and it must be at
the end of the structure). You access the open-ended array of objects just
as you would any other array embedded within a structure, E.G.
instance->ar_args[n].
Not all compilers support defining zero-length arrays like this. And that's
a pity; it's an incredibly useful technique, and the alternatives to it are
not nearly as elegant and generally involve ugly recasting of pointers.
-- Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: A few questions about a few includes
On Sun, Mar 03, 2002 at 10:27:17AM -0700, Ian wrote:
> >
> > In :
> >
> > /*
> > * pargs, used to hold a copy of the command line, if it had a sane
> > * length
> > */
> > struct pargs {
> > u_int ar_ref; /* Reference count */
> > u_int ar_length; /* Length */
> > u_char ar_args[0]; /* Arguments */
> > };
> >
> > This does indeed seem to make little or no sense. Could someone explain
> > this? Is ar_args supposed to be a pointer or what?
>
> This is a common technique for defining a structure which is some
> descriptive information about an array of objects is followed by an
> open-ended array of those objects. (In this case the "objects" are
> characters.) The ar_args member of the structure gives a name to that
> location in the structure without reserving any space (and thus when the
> technique is used, there can only ever be one [0] member and it must be at
> the end of the structure). You access the open-ended array of objects just
> as you would any other array embedded within a structure, E.G.
> instance->ar_args[n].
>
> Not all compilers support defining zero-length arrays like this. And that's
> a pity; it's an incredibly useful technique, and the alternatives to it are
> not nearly as elegant and generally involve ugly recasting of pointers.
For those compilers that don't support zero-length arrays one can still
use the same trick but with a one-element array at the end of the
struct. One just has to remember to that element into account when
allocating memory for the structure. Slightly uglier, but not much.
It might be worth mentioning that this trick is not actually allowed
according to the C standard and in principle invokes undefined
behaviour. OTOH, AFAIK the trick does work on all existing compilers,
so while it is not standard-conforming it is quite portable.
--
Erik Trulsson
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
December 2001, January 2002 Bi-Monthly FreeBSD Status Report
Attached below, please find the text version of the bi-monthloy status
report. It's actually been up on the web for a few days. Apologies for
any delays :-). It's worth noting that report submission has dropped
off a bit for this report, and I hope for better on the next report, for
which I'll begin to collect entries in about three weeks.
December 2001 - January 2002 Status Report
Introduction
This bi-monthly report covers development activities on the FreeBSD
Project for December 2001 and January 2002. A variety of accomplishments
have been made over the last couple of months, including strong progress
relating to the KSE project, which brings Scheduler Activations to the
FreeBSD kernel, as well as less visible infrastructure projects such as
improvements to the mount interface, PAM integration work, and translation
efforts. Shortly following the deadline for this status report, the BSD
Conference and FreeBSD Developer Summit were held, and will be covered in
the next bi-monthly report at the end of March. Plans are already under
way for the USENIX Annual Technical Conference in Monterey, CA, later this
year, and all and sundry are encouraged to attend to get further insight
in FreeBSD development.
Robert Watson
* "GEOM" - generalized block storage manipulation
* Bluetooth stack for FreeBSD (Netgraph implementation)
* FreeBSD C99 & POSIX Conformance Project
* FreeBSD in Bulgarian
* FreeBSD Java Project
* jp.FreeBSD.org daily SNAPSHOTs project
* jpman project
* KAME
* KSE Status Report
* Netgraph ATM
* New mount(2) API
* Pluggable Authentication Modules
* Revised {mode,log}page support for camcontrol
* SMPng
* TrustedBSD ACLs
* TrustedBSD Audit
* TrustedBSD MAC Implementation
* USB stack maintenance
"GEOM" - generalized block storage manipulation
URL: http://www.freebsd.org/~phk/Geom/
Contact: Poul-Henning Kamp <[EMAIL PROTECTED]>
This project is now finally underway, thanks to DARPA and NAI getting a
sponsorship lined up. The infrastructure code and data structures are
currently taking form inside a userland simulation harness. Basic MBR and
BSD methods have been written and device attach/taste/dettach algorithms
been implemented and validated.
--
Bluetooth stack for FreeBSD (Netgraph implementation)
Contact: Maksim Yevmenkin <[EMAIL PROTECTED]>
The project is making progress. The goal is to design and implement Host
Controller Interface (HCI) and Link Layer Control and Adaptation Protocol
(L2CAP) layers using Netgraph framework. More distant goal is to write
support for Service Discovery Protocol (SDP) and RFCOMM protocol (Serial
port emulation over Bluetooth link) . All information was obtained from
Bluetooth Specification Book v1.1.
Project status: In progress. 1) Design: mostly complete, there are some
minor issues to be resolved. 2) Implementation: Kernel - HCI and L2CAP
Netgraph nodes have been implemented; 3) User space (API, library,
utilities) - in progress. 4) Testing: In progress. I do not have real
Bluetooth hardware at this point, so i wrote some tools that allow me to
test the code. Some of them will be used as foundation for future user
space utilities.
Issues: 1) Bluetooth hardware; I do not have real Bluetooth hardware, so
if people can donate hardware/specs it would be great. I promise to write
all required drivers and make them available. I also promise to return
hardware/specs on first request. 2) Project name; I would like to see the
name that reflects the following: it is a Bluetooth stack, implementation
is for FreeBSD and implementation is based on Netgraph framework
--
FreeBSD C99 & POSIX Conformance Project
URL: http://people.FreeBSD.org/~mike/c99/
Contact: Mike Barcroft <[EMAIL PROTECTED]>
Contact: FreeBSD-Standards Mailing List <[EMAIL PROTECTED]>
A significant amount of progress was made in December and January,
particularly in the area of utility conformance. Several utilities were
updated to conform to SUSv3, they include: at(1), mailx(1), pwd(1),
split(1), and uudecode(1). Several patches have been submitted to increase
conformance in other utilities, they include: fold(1), patch(1), m4(1),
nice(1), pr(1), renice(1), wc(1), and xargs(1). These are in the process
of being reviewed and committed. Two new utilities have been written,
specifically pathchk(1) and tabs(1). These are also being reviewed and
will be committed shortly.
A patch which implements most of the requirements of scanf(3) is being
reviewed and is expected to be committed shortly. This will allow us to
MFC a number of new fun
Re: A few questions about a few includes
On Sunday 03 March 2002 10:19 am, Conrad Sabatier wrote:
> Am I just completely stupid, or do we have a few things that could use a
> little cleaning up in /usr/include as well as in the man page for kvm_*?
>
> System: FreeBSD 4.5-STABLE
>
> 2) If compiling with the -pedantic switch, one might see something like
>this:
>
> In file included from main.c:151:
> /usr/include/sys/proc.h:108: warning: ANSI C forbids zero-size array
> `ar_args'
>
> In :
>
> /*
> * pargs, used to hold a copy of the command line, if it had a sane
> * length
> */
> struct pargs {
> u_int ar_ref; /* Reference count */
> u_int ar_length; /* Length */
> u_char ar_args[0]; /* Arguments */
> };
>
> This does indeed seem to make little or no sense. Could someone explain
> this? Is ar_args supposed to be a pointer or what?
I can explain this one; it's a moderately-common C programming technique.
This strucuture will be allocated dynamically. I could be declared like
struct pargs { ... u_char *ar_args; }
and allocated like
pargs = malloc(sizeof(struct pargs));
pargs->ar_args = malloc(args_size);
but it's a lot more efficient to declare it as above and allocate it as
pargs = malloc(sizeof(struct pargs) + args_+size);
since pointers & arrays are equivalent, except that array data is at the
location of the name rather than having a pointer to the data at that
location, a [0] array has exactly the right semantics for this. You can
declare a [1] array for this to make ANSI happy, but then you have to
subtract in the allocation and besides that the [0] is "self-documenting" for
those who are familir with the technique--after all, there isn't anything
*else* you can do with a [0]-sized array.
> 3) Furthermore, on including , one then sees this:
>
> In file included from /usr/include/sys/user.h:40,
> from main.c:153:
> /usr/include/machine/pcb.h:90: warning: struct has no members
>
> In :
>
> /*
> * The pcb is augmented with machine-dependent additional data for
> * core dumps. For the i386: ???
> */
> struct md_coredump {
> };
>
> Nowhere under /usr/include is a more complete definition of md_coredump to
> be found. This looks awfully "kludgy" to me.
A little guesswork here, but this seems pretty self-explanatory to me, too.
The md_coredump{} is a structure that includes the *extra* information
(beyond what's already in the portable structure) for coredumps on a given
architecture. In the case of the 386, there is no useful extra information,
so the structure is empty, but since there's a structure someplace that has
an instance of struct md_coredump, it must be declared. Since there's no
useful content, it is declared as being empty.
Seems pretty elegant to me.
If I'm off-base here, somebody please jump in!
>
> I do hope someone can shed some light here. Thanks.
[Your point #1 seems valid to me, though.]
--
Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work)
Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal)
ME --> http://www.babbleon.org
http://www.eff.org <-- GOOD GUYS --> http://www.programming-freedom.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
periodic firewire max-out question
I still do not yet own 63 firewire devices, and so, once again, I am wondering if anyone here has ever actually connected 128 devices to a firewire host adaptor and had operational success... (or heard reports of it being successfully done in the wild ?) Comments welcome. thanks. - John Kozubik - [EMAIL PROTECTED] - http://www.kozubik.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A few questions about a few includes
On Sunday 03 March 2002 01:00 pm, Erik Trulsson wrote:
> On Sun, Mar 03, 2002 at 10:27:17AM -0700, Ian wrote:
> > > In :
> > >
> > > /*
> > > * pargs, used to hold a copy of the command line, if it had a sane
> > > * length
> > > */
> > > struct pargs {
> > > u_int ar_ref; /* Reference count */
> > > u_int ar_length; /* Length */
> > > u_char ar_args[0]; /* Arguments */
> > > };
>
> It might be worth mentioning that this trick is not actually allowed
> according to the C standard and in principle invokes undefined
> behaviour. OTOH, AFAIK the trick does work on all existing compilers,
> so while it is not standard-conforming it is quite portable.
I can't even imagine how one *would* write a compiler where this would
fail--does anybody know the putative risk that led ANSI to "ban" this (IMHO)
perfectly-reasonable bahvior?
--
Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work)
Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal)
ME --> http://www.babbleon.org
http://www.eff.org <-- GOOD GUYS --> http://www.programming-freedom.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: A few questions about a few includes
"Brian T.Schellenberger" wrote:
> I can't even imagine how one *would* write a compiler where this would
> fail--does anybody know the putative risk that led ANSI to "ban" this (IMHO)
> perfectly-reasonable bahvior?
Order of structure elements is undefined. Zero length arrays
are undefined. Also, packing is undefined.
You can basically get arouns all of this by declaring the
array to be 1 byte, e.g.:
struct pargs {
u_int ar_ref; /* Reference count */
u_int ar_length; /* Length */
u_char ar_args[1]; /* Arguments */
};
And then sizing the allocation unit relatively, e.g., dont
use:
sizeof(struct pargs) + byte_count
use instead:
(int)&((struct pargs *)0)->ar_args + byte_count;
To get the size of the elements up to but not including
the one byte declared, regardless of alignment or packing.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: A few questions about a few includes
Terry Lambert wrote: | Order of structure elements is undefined. Zero length arrays | are undefined. Also, packing is undefined. Close, but no cigar. The /order/ is defined in C89 (Section 6.5.2.1) with the following words: Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. Greg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A few questions about a few includes
Thanks for all the very interesting followups, folks. I learned something today! I really must start reading this list more often. :-) -- Conrad Sabatier <[EMAIL PROTECTED]> Bennett's Laws of Horticulture: (1) Houses are for people to live in. (2) Gardens are for plants to live in. (3) There is no such thing as a houseplant. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
