Re: UFS large directory performance

[Terry Lambert]

Ian Dowse wrote:
> >The only potential problem I see here is that you could
> >end up seriously fragmenting the malloc pool you are
> >using to allocate the slot arrays.  And, of course, the
> >two issues you brought up in regards to regularing memory
> >use.
> 
> Thanks for the comments :-) Yes, malloc pool fragmentation is a
> problem. I think that it can be addressed to some extent by using
> a 2-level system (an array of pointers to fixed-size arrays) instead
> of a single large array, but I'm open to any better suggestions.

Use a chain allocator.  I would suggest using the zone
allocator, but it has some fundamental problems that I
don't think are really resolvable without a rewrite.

Unlike the zone allocator, which rounds to 64 byte units,
a chain allocator allocates a free chain that is fit to
a 32 bit boundary (4 bytes instead of 64, for an average
wastage of 2, instead of 32, bytes, if there is any at
all).

In addition, the allocator will allocate based on least
common multiple (after 32 bit rounding), and will use a
backing object size to get the multiple.  For a 60 byte
object, this would mean allocating 15 pages, and dividing
it into 1024 objexts (2048 for Alpha, with its 8k page
size).  But the memory can be backed by kmem_malloc() or
alloc(), which allocates page units, instead of by the
power of 2 allocator.  And there are zero bytes wasted.

The memory also need not be permanently type stable,
like memory in a zone, though you would need to build a
reclaimer that ran in the background.  You could make
it deterministic, by sorting the freelist in chunks of
the allocation unit at a time (see Knuth; a quicksort
is really not appropriate).  You could use a second
level reclaim to return memory to the system; this would
effectively make it a hybrid between the Dynix zone
allocator (on which it is modelled), and a slab allocator.

Finally, you could maintain per-cpu chains to allow the
allocations and frees to occur on a per CPU basis; that
would mean that there was no IPI or bus contention for
allocations or deallocations (whether you want to defer
migration of objects to the chains of their home CPU, or
let the free to the system at a low watermark take care
of that for you, giving preference to frees of non-local
origin elements, is reall a policy decision).

I've actually written one of these, without the Dynix
style reclaimer (e.g. the memory becomes type stable only
after allocation, which makes it an improvement on the
zone allocator, at the cost of not being usable at
interrupt time for allocations), as part of some performance
improvement work in a modified FreeBSD kernel.


> If the second-level array size was fixed at around 4k, that would
> keep the variable-length first-level array small enough not to
> cause too many fragmentation issues. The per-DIRBLKSIZ free space
> summary array is probably relatively okay as it is now.

If you are going to fix it, and your object happens to be
an even power of 2 in size, at the very least, make the
backing object be the page size, so it will still work well
on the Alpha, without page fragmentation.

I rather expect that the IA64 will end up forcing our
Intel page size to be increased.

> The other main issue, that of discarding old hashes when the memory
> limit is reached, may be quite tricky to resolve. Any approach
> based on doing this from ufsdirhash_build() is likely to become a
> locking nightmare. My original idea was to have ufsdirhash_build()
> walk a list of other inodes with hashes attached and free them if
> possible, but that would involve locking the other inode, so things
> could get messy.


Add an LRU field, and lock the hashes on a "32 object at
a time" or similarly high granularity.  This is more
natural with a chain block, of course, but works well in
any case.

I have been considering moving the per process open file
table into a direct/indirect object list, similar to the
SVR4 method, rather than the size doubling, for similar
performance reasons.  Locking a block of files, and
maintaining per block freelists (instead of a hints pointer
-- what the heck else are you keeping in those idle structs
anyway, such that you _shouldn't_ be cating them into a
list?!?).

If you poke around in that area long enough, you'll see
that there are some "magic" numbers like "NFILES", which
started out as an optimization, but which all the recent
additions for things like kqueue event chains have turned
into hopeless pessimizations.  8-(.

-- Terry



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

Re: UFS large directory performance

[Terry Lambert]

Ian Dowse wrote:
> Nice idea, but I'm not sure I see the benefit of partially reclaiming
> second-level arrays. Because it is a hash array, there isn't really
> the concept of a working set; a directory that is `in use' will
> rarely see many create/rename/delete operations on a small fixed
> set of filenames. The lookup case is already cached elsewhere. I
> think an all-or-nothing approach is likely to perform better and
> be simpler to implement. Even the lazy allocation of second-level
> arrays is unlikely to help a lot if the hash function does its job
> well.

>From this perspective, it seems to me that there could be
significant benefit in getting rid of the ihash cache; but
then I've always hated the thing, since there's no way to
reassociate a vnode with valid, clean data hanging off it
with an ihash entry, when you get an ihash cache hit.

Totally off the dirpref topic, cut of the same philosophical
bent that your statement above seems to advocate...

-- Terry

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

New error - lost data?

[Deepak Jain]

I've never seen this error. Its been occuring randomly on this machine,
sometimes as often as every few minutes, sometimes days apart.

Others have seen this error (based on a Google search) but nothing recent
and nothing that conclusive. This is a very standard config that has been
stable for quite a while. The panic: malloc: lost data implies to me that
something is misbehaving with its memory allocations.

Is this a hardware issue or an application problem? The kernel is 4.1
RELEASE. The RAM is ECC.

Any assistance would be appreciated!

Thanks,

Deepak Jain
AiNET


Jun  5 01:02:56 play /kernel: panic: malloc: lost data
Jun  5 01:02:56 play /kernel:
Jun  5 01:02:56 play /kernel: syncing disks... 440 440 440 440 440 440 440
440
Jun  5 01:02:56 play /kernel: giving up on 433 buffers
Jun  5 01:02:56 play /kernel: Uptime: 3m11s



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

Re: How to disable software TCP checksumming?

[Terry Lambert]

Bill Fenner wrote:
> 
> >The TCP checksum protects more than just the contents of the packet
> >on the wire; it's also a (somewhat) weak check on the contents
> >of your packet sitting in memory, and as it's going over the bus
> >in your computer between memory and peripherals and for other
> >end-to-end sorts of issues.
> 
> In fact, Jonathan Stone at Stanford did some measurements of
> checksum errors for his thesis, and found that on a given link
> in the Stanford residences there were a surprising (small, but
> measurable) number of packets with IP header checksum errors
> with what appeared to be DMA errors -- e.g. 4 bytes missing
> from the middle of the header.  When the end to end checksum
> is really memory to memory, it can catch errors like this...

You need to read the ethernet drivers in /sys/pci/if_*...

Specifically, look for m_devget() uses, and the comments
about why they are necessary.

I will bet you that the 4 byte "holes" that appear to be
"DMA errors" are actually driver errors, with drivers
sending unaligned packets down to the the DMA engine.

Further, if you characterize them, I bet you will see that
the majority of them are Linux machines.

The problem is that many cards require 4 byte alignment (one
of the gigabit cards requires 64 bit alignment) for the DMA
engine on the card to function properly.

This annoys the piss out of TCP/IP stacks in host machines,
which like to cast headers to pointers, and directly access
the packet header contents.

Naieve driver writers will do a 2 byte align on their
assembled TCP/IP packets (causing the IP address to be
on a 4 + 2 byte boundary, instead of a 4 byte boundary,
and the DMA engine will choke.

This all came from IP headers being 14 bytes long, instead
of 16.

Why card manufacturers can't make their DMA engine use an
offset shif buffer is beyond me, but they don't do that,
and so unaligned accesses happen.

This slows down host processing, best case; worst case, the
host is not careful to make the cards happy, and "holes"
appear.

In fact, it would not surprise me if the person conducting
the research had the problem on his system, and the stuff
on the network itself was actually all right, since it is
generally a receive processing introduced error.  8-).

In any case, I still would like an option to turn on the
processing in the card, and let me assume that my hardware
is monolithic, my card supports checksum offloading, and
if I have problems with corruption between my ethernet
card and my CPU, I have really, reall bad problems because
the CPU and the etherent interface are sitting on the same
silicon die which they were fabricated to share.


-- Terry

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

Re: free() and const warnings

[Peter Pentchev]

On Thu, Jun 07, 2001 at 10:20:51AM -0700, John Baldwin wrote:
> 
> On 07-Jun-01 Peter Pentchev wrote:
> > On Thu, Jun 07, 2001 at 07:07:22PM +0300, Peter Pentchev wrote:
> >> Hi,
> >> 
> >> Is free((void *) (size_t) ptr) the only way to free a const whatever *ptr
> >> with WARNS=2?  (or more specifically, with -Wcast-qual)
> > 
> > Uhm.  OK.  So size_t may not be enough to hold a pointer.  What is it then -
> > caddr_t?
> 
> uintptr_t for data pointers.  In theory I think code pointers may not fit in a
> uintptr_t.
> 
> free((void *)(uintptr_t)ptr) should work.
> 
> Of course, this begs the question of why you are free'ing a const. :)

OK, here's a scenario:

struct validation_fun {
const char  *name;
valfun  *fun;
int dyn;
};

This is a structure for a set of validation functions, referenced by
name from another type of object.  There are some predefined functions,
present in the code at compile-time, and hardcoded in an array, with
names given as "strings".  Thus, the 'const'.

However, some of the functions may be defined at runtime, with both
name and code sent by a server.  In that case, the name is a dynamically
allocated char *, which needs to be freed upon cleanup.  So I have:

[cleanup function]
...
if (val->dyn)
free(val->name);

Any suggestions on how to improve the design to avoid this, if possible,
would be greatly welcome.

G'luck,
Peter

-- 
I am the meaning of this sentence.

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

Re: [Patch?] signal(SIGCHLD, SIG_IGN) is against SUSv2

[Terry Lambert]

Cejka Rudolf wrote:
> 
> There is following paragraph in SUSv2:
> 
>   If a process sets the action for the SIGCHLD signal to SIG_IGN,
>   the behaviour is unspecified, except as specified below. If the
>   action for the SIGCHLD signal is set to SIG_IGN, child processes
>   of the calling processes will not be transformed into zombie
>   processes when they terminate. If the calling process subsequently
>   waits for its children, and the process has no unwaited for children
>   that were transformed into zombie processes, it will block until all
>   of its children terminate, and wait(), wait3(), waitid() and waitpid()
>   will fail and set errno to [ECHILD]. ...
> 
> However, if I use "signal(SIGCHLD, SIG_IGN)", zombies are still
> created in FreeBSD, which is against SUSv2.

Look at the sigaction() man page.  There is a POSIX way
to do what you want, using the sa_flags bits.

If you hack up signal() to do this, it should be done
by noting the SIG_IGN and the fact you are using the
historical compatability signal() wrapper to the POSIX
interface, and just set the sa_flags bit to do the job.

I'm pretty sure the "wait" and other behaviour is also
documented on that page, in the context of the sa_flags
bit.

-- Terry

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

Re: read(2) and ETIMEDOUT

[Terry Lambert]

Ian Dowse wrote:
> 
> In message <[EMAIL PROTECTED]>, Graham Barr writes:
> 
> >Also why does this happen only every few hours ? There is a lot of
> >data going through these connections maybe the timer for SO_RCVTIMEO
> >is not being reset.
> >
> >But then we have another server, with a similar number of clients and
> >data through put, but it does not suffer from this problem.
> 
> I suspect that the server seeing this problem has a client that
> occasionally disappears from the network, or for whatever reason
> fails to respond to any packets for a long time (something like 5
> or 10 minutes). I've seen blocking TCP writes return ETIMEDOUT when
> the network between the client and the server goes down. In the
> non-blocking case I think the following can happen:

I believe the proxy ARP normally sent on an interface
coming up can have this effect in the case a client goes
down, and someone else gets their DHCP lease.

You don't often see this on FreeBSD clients after 4.1,
since the gratuitous proxy ARP became broken around then
(if you change your IP address, it won't send the ARP
unless you down the interface first and bring it back up,
and it caches bad clone routes, too, just to make your
life miserable).

Probably your lease expiration times are set too low.  This
is usually the case in networks where people have transient
connections for things like mobile users, and have exhaused
their IP address space, and are trying to conserve it by
using much shorter leases.

A good, real fix for this is to have incredibly long lease
lifetimes (basically, the DHCP server hands out the lease,
and if the computer comes back days later, it gets the same
lease).  For this to work, you are probably going to have
to make the local DHCP server give out 10.x addresses, and
then NAT the 10.x net for real Internet connectivity.

Alternately, it could be something completely different.  8-).

-- Terry

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

Re: Why does fsck try to fsck a CDROM?

[Terry Lambert]

Dave Hayes wrote:
> 
> David O'Brien -Hackers <[EMAIL PROTECTED]> writes:
> > You mentioned though that your CDROM is /.  How about posting the real
> > /etc/fstab from your root partition for us to have a look at?
> 
> There is none. No default fstab exists.

There is no Dana, only Zuul...

I think that root gets fsck'ed in the rc files, even if
there is no /etc/fstab, on the theory that that might be
one of the reasons fsck needs to be run.

Fsck normally runs on root when it is mounted r/o, and
root gets mounted r/w only after it passes.

The question is whether you can distinguish between a
r/o device vs. a r/o mount of a r/w device... that is
what fsck would have to do to decide to skip the fsck
entirely for a cdrom.

...on the other hand, you could have burnt a dirty FS
on the CDROM, in which case, it should check it and
refuse to boot until you "fix" the errors by running
fsck manually (quite the trick with the hole in it)...

8-).

-- Terry

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

Re: UFS large directory performance

[Ian Dowse]

In message <[EMAIL PROTECTED]>, Terry Lambert writes:
>
>Use a chain allocator.  I would suggest using the zone
>allocator, but it has some fundamental problems that I
>don't think are really resolvable without a rewrite.

Heh, maybe, but I'm not sure I want to write a new allocator for
this :-) Based on Matt's suggestions, I implemented the 2-level
approach. It currently uses 256 slots per second-level block; these
1k blocks are allocated using zalloc(). The variable-length
first-level arrays are still allocated with malloc, but these don't
grow to more than a few kb in size unless the directories are
enormous.

There's now a simple LRU list of dirhash structures that have memory
attached, and a new function ufsdirhash_recycle() that will free
up memory when the sysctl limit is reached. Adding this required
some locking, but the problematic inode locking is avoided by
leaving the dirhash structure attached to the inode when its hash
array is freed.

An updated patch is available at

http://www.maths.tcd.ie/~iedowse/FreeBSD/dirhash.diff3

I haven't had a chance to do more than a minimal amount of testing,
so there may be many issues remaining.

Ian

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

Re: free() and const warnings

[Thomas David Rivers]

Peter Pentchev <[EMAIL PROTECTED]> wrote:
> 
> On Thu, Jun 07, 2001 at 10:20:51AM -0700, John Baldwin wrote:
> > 
> > On 07-Jun-01 Peter Pentchev wrote:
> > > On Thu, Jun 07, 2001 at 07:07:22PM +0300, Peter Pentchev wrote:
> > >> Hi,
> > >> 
> > >> Is free((void *) (size_t) ptr) the only way to free a const whatever *ptr
> > >> with WARNS=2?  (or more specifically, with -Wcast-qual)
> > > 
> > > Uhm.  OK.  So size_t may not be enough to hold a pointer.  What is it then -
> > > caddr_t?
> > 
> > uintptr_t for data pointers.  In theory I think code pointers may not fit in a
> > uintptr_t.
> > 
> > free((void *)(uintptr_t)ptr) should work.
> > 
> > Of course, this begs the question of why you are free'ing a const. :)
> 
> OK, here's a scenario:
> 
> struct validation_fun {
>   const char  *name;
>   valfun  *fun;
>   int dyn;
> };
> 
> This is a structure for a set of validation functions, referenced by
> name from another type of object.  There are some predefined functions,
> present in the code at compile-time, and hardcoded in an array, with
> names given as "strings".  Thus, the 'const'.
> 
> However, some of the functions may be defined at runtime, with both
> name and code sent by a server.  In that case, the name is a dynamically
> allocated char *, which needs to be freed upon cleanup.  So I have:
> 
> [cleanup function]
>   ...
>   if (val->dyn)
>   free(val->name);
> 
> Any suggestions on how to improve the design to avoid this, if possible,
> would be greatly welcome.
> 
> G'luck,
> Peter

 Since some strings are non-constant (the are allocated) - I believe
 the `const' qualifier in the structure declaration is incorrect.

 What happens if you simply don't have it in the structure declaration?

- Dave Rivers -

--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com



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

problem with systm.h trying to call resettodr()

[Rasputin]

I'm playing with resettodr(9), to set the BIOS clock from the system time..

When I try to compile the following snippet,

[rasputin@dogma rasputin]$ cat b0rken.c 
#include 
#include 
#include 

int main(void){
resettodr();
return(0);
}

I get warning about syntax errors in systm.h:

[rasputin@dogma rasputin]$ gcc b0rken.c 
In file included from b0rken.c:3:
/usr/include/sys/systm.h:333: syntax error before `int'
/usr/include/sys/systm.h:334: syntax error before `int'
/usr/include/sys/systm.h:335: syntax error before `('

(System is STABLE/RELENG_4 freshly cvsupped a few days ago, although
/usr/src/sys/sys/systm.h doesn't seem to have changed in STABLE
for four months.

Any ideas? I know I'm not exactly '3l337' but I'd say that header file
was screwed. Or am I missing some wierd ass compiler option?

Thanks.

-- 
What you don't know can hurt you, only you won't know it.
Rasputin :: Jack of All Trades - Master of Nuns ::

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

Re: problem with systm.h trying to call resettodr()

[Louis A. Mamakos]

I didn't think resettodr(9) was a system call exposed to user program,
but instead a function available to be called from kernel code.  Thus,
the section 9 manual page.

louie

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

Re: 'make clean' vs automake vs /bin/sh, which to fix?

[Assar Westerlund]

Garance A Drosihn <[EMAIL PROTECTED]> writes:
> So, we could fix this by:
>  1) changing /bin/sh

This you have already done and I think it's ok.

>  2) changing make not to call /bin/sh with -e
>  3) changing 'automake' to include a "true;" statement
> in that 'for' loop (or some other trick) when
> spitting out the target for things like clean-recursive

I believe this has also been fixed in more modern automake.

/assar

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

Re: How to disable software TCP checksumming?

[Assar Westerlund]

Terry Lambert <[EMAIL PROTECTED]> writes:
> This all came from IP headers being 14 bytes long, instead
> of 16.

Hu?  An IPv4 header (not including options) is 20 bytes long.

/assar

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

Re: problem with systm.h trying to call resettodr()

[Peter Pentchev]

On Fri, Jun 08, 2001 at 12:47:31PM +0100, Rasputin wrote:
> I'm playing with resettodr(9), to set the BIOS clock from the system time..
> 
> When I try to compile the following snippet,
> 
> [rasputin@dogma rasputin]$ cat b0rken.c 
> #include 
> #include 
> #include 
> 
> int main(void){
> resettodr();
> return(0);
> }
> 
> I get warning about syntax errors in systm.h:
> 
> [rasputin@dogma rasputin]$ gcc b0rken.c 
> In file included from b0rken.c:3:
> /usr/include/sys/systm.h:333: syntax error before `int'
> /usr/include/sys/systm.h:334: syntax error before `int'
> /usr/include/sys/systm.h:335: syntax error before `('
> 
> (System is STABLE/RELENG_4 freshly cvsupped a few days ago, although
> /usr/src/sys/sys/systm.h doesn't seem to have changed in STABLE
> for four months.
> 
> Any ideas? I know I'm not exactly '3l337' but I'd say that header file
> was screwed. Or am I missing some wierd ass compiler option?

As others pointed out, resettodr(9) is a kernel-space function.
Section 9 of the manual is for those - see the intro(9) manual page
with man 9 intro (just man intro would probably show you intro(1)).

G'luck,
Peter

-- 
If I had finished this sentence,

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

Re: How to disable software TCP checksumming?

[Ruslan Ermilov]

On Fri, Jun 08, 2001 at 02:24:23PM +0200, Assar Westerlund wrote:
> Terry Lambert <[EMAIL PROTECTED]> writes:
> > This all came from IP headers being 14 bytes long, instead
> > of 16.
> 
> Hu?  An IPv4 header (not including options) is 20 bytes long.
> 
Terry meant the length of an IPv4 header up to but not including
the checksum field.


Cheers,
-- 
Ruslan Ermilov  Oracle Developer/DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age

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

Re: problem with systm.h trying to call resettodr()

[Ceri]

On Fri, Jun 08, 2001 at 12:47:31PM +0100, Rasputin said:
> I'm playing with resettodr(9), to set the BIOS clock from the system time..
> 
> I get warning about syntax errors in systm.h:
> 
> [rasputin@dogma rasputin]$ gcc b0rken.c 
> In file included from b0rken.c:3:
> /usr/include/sys/systm.h:333: syntax error before `int'
> /usr/include/sys/systm.h:334: syntax error before `int'
> /usr/include/sys/systm.h:335: syntax error before `('

I been getting the exact same thing, so it's definitely not local to you.

Ceri

-- 
Your local RFC Nazi

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

Re: How to disable software TCP checksumming?

[Assar Westerlund]

Ruslan Ermilov <[EMAIL PROTECTED]> writes:
> On Fri, Jun 08, 2001 at 02:24:23PM +0200, Assar Westerlund wrote:
> > Terry Lambert <[EMAIL PROTECTED]> writes:
> > > This all came from IP headers being 14 bytes long, instead
> > > of 16.
> > 
> > Hu?  An IPv4 header (not including options) is 20 bytes long.
> > 
> Terry meant the length of an IPv4 header up to but not including
> the checksum field.

I'm confused.  From rfc791:

0   1   2   3   
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|  Total Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Identification|Flags|  Fragment Offset|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |Protocol   | Header Checksum   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Source Address  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Destination Address|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Options|Padding|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Which to me says that an IP header up to but not including the
checksum is 10 bytes?

/assar

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

Re: free() and const warnings

[Peter Pentchev]

On Fri, Jun 08, 2001 at 06:55:50AM -0400, Thomas David Rivers wrote:
> Peter Pentchev <[EMAIL PROTECTED]> wrote:
> > 
> > On Thu, Jun 07, 2001 at 10:20:51AM -0700, John Baldwin wrote:
> > > 
> > > On 07-Jun-01 Peter Pentchev wrote:
> > > > On Thu, Jun 07, 2001 at 07:07:22PM +0300, Peter Pentchev wrote:
> > > >> Hi,
> > > >> 
> > > >> Is free((void *) (size_t) ptr) the only way to free a const whatever *ptr
> > > >> with WARNS=2?  (or more specifically, with -Wcast-qual)
> > > > 
> > > > Uhm.  OK.  So size_t may not be enough to hold a pointer.  What is it then -
> > > > caddr_t?
> > > 
> > > uintptr_t for data pointers.  In theory I think code pointers may not fit in a
> > > uintptr_t.
> > > 
> > > free((void *)(uintptr_t)ptr) should work.
> > > 
> > > Of course, this begs the question of why you are free'ing a const. :)
> > 
> > OK, here's a scenario:
> > 
> > struct validation_fun {
> > const char  *name;
> > valfun  *fun;
> > int dyn;
> > };
> > 
> > This is a structure for a set of validation functions, referenced by
> > name from another type of object.  There are some predefined functions,
> > present in the code at compile-time, and hardcoded in an array, with
> > names given as "strings".  Thus, the 'const'.
> > 
> > However, some of the functions may be defined at runtime, with both
> > name and code sent by a server.  In that case, the name is a dynamically
> > allocated char *, which needs to be freed upon cleanup.  So I have:
> > 
> > [cleanup function]
> > ...
> > if (val->dyn)
> > free(val->name);
> > 
> > Any suggestions on how to improve the design to avoid this, if possible,
> > would be greatly welcome.
> > 
> > G'luck,
> > Peter
> 
>  Since some strings are non-constant (the are allocated) - I believe
>  the `const' qualifier in the structure declaration is incorrect.
> 
>  What happens if you simply don't have it in the structure declaration?

GCC complains when I try to initialize the structure with something like:

struct validation_fun   val_init[] = {
{"init",valfun_init,0}
};

This can be avoided by:

struct validation_fun   val_init[] = {
{(char *) (uintptr_t) "init",   valfun_init,0}
};

..but as a matter of fact, static, pre-initialized valfun structs are
the rule rather than the exception in this program, so having this
syntax for all of them seems.. well.. ugly :)

G'luck,
Peter

-- 
You have, of course, just begun reading the sentence that you have just finished 
reading.

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

Re: problem with systm.h trying to call resettodr()

[Rasputin]

* Peter Pentchev <[EMAIL PROTECTED]> [010608 13:35]:
> On Fri, Jun 08, 2001 at 12:47:31PM +0100, Rasputin wrote:
> > I'm playing with resettodr(9), to set the BIOS clock from the system time..

> As others pointed out, resettodr(9) is a kernel-space function.
> Section 9 of the manual is for those - see the intro(9) manual page
> with man 9 intro (just man intro would probably show you intro(1)).

Thanks, I'd already read intro(9), but it doesn't explain how to *use*
kernel-space functions. 


I suppose the manpage would be huge then, though maybe book size?
Is this another 'get that daemon book, you tight-fisted...' 
situation?

So the syntax errors in systm.h are related to what-
Missing compiler flags (-DKERNEL?), or missing headers?



I *know* you guys all know, but where did you get this knowledge from?
Is there a secret BSD monastery you all hang out at, or is there a secret
switch you give man that lets you into the *real* details ?


Thanks. I'll bring water wings next time

--
"These are the propulsion systems used by NASA for the moonshots,"
said Tom apologetically. 
Rasputin :: Jack of All Trades - Master of Nuns ::

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

Re: free() and const warnings

[Thomas David Rivers]

> 
> GCC complains when I try to initialize the structure with something like:
> 
> struct validation_fun val_init[] = {
>   {"init",valfun_init,0}
> };
> 
> This can be avoided by:
> 
> struct validation_fun val_init[] = {
>   {(char *) (uintptr_t) "init",   valfun_init,0}
> };
> 
> ..but as a matter of fact, static, pre-initialized valfun structs are
> the rule rather than the exception in this program, so having this
> syntax for all of them seems.. well.. ugly :)
> 

 Ah..   I see..

 (I don't think you need (uintptr_t) - you can cast a (const char *)
  to a (char *) without having to go "through" that - I believe.)

 Is this C, or C++.. there are some differences in the type of
 a constant character string between the two...

 But - basically, what you are trying to describe is a field which
 is sometimes 'const' and othertimes isn't... which doesn't make 
 sense in the context of the C standard...  you'll need a cast
 for the initialization, or some other approach besides static
 initialization I believe... (or, just "live" with the warning...
 which isn't pleasant at all.)

- Dave R. -

--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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

Re: problem with systm.h trying to call resettodr()

[Peter Pentchev]

On Fri, Jun 08, 2001 at 01:49:12PM +0100, Rasputin wrote:
> * Peter Pentchev <[EMAIL PROTECTED]> [010608 13:35]:
> > On Fri, Jun 08, 2001 at 12:47:31PM +0100, Rasputin wrote:
> > > I'm playing with resettodr(9), to set the BIOS clock from the system time..
> 
> > As others pointed out, resettodr(9) is a kernel-space function.
> > Section 9 of the manual is for those - see the intro(9) manual page
> > with man 9 intro (just man intro would probably show you intro(1)).
> 
> Thanks, I'd already read intro(9), but it doesn't explain how to *use*
> kernel-space functions. 

You can only use kernel-space functions in kernel code, that is, writing
a kernel module, or writing a piece of code that is to be compiled along
with the rest in src/sys.

If you're doing that, look at some kernel source files to see which header
files need to be included.  If you're not doing that, you cannot use
the functions documented in section 9.

G'luck,
Peter

-- 
This sentence claims to be an Epimenides paradox, but it is lying.

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

Re: free() and const warnings

[Peter Pentchev]

On Fri, Jun 08, 2001 at 08:51:54AM -0400, Thomas David Rivers wrote:
> > 
> > GCC complains when I try to initialize the structure with something like:
> > 
> > struct validation_fun   val_init[] = {
> > {"init",valfun_init,0}
> > };
> > 
> > This can be avoided by:
> > 
> > struct validation_fun   val_init[] = {
> > {(char *) (uintptr_t) "init",   valfun_init,0}
> > };
> > 
> > ..but as a matter of fact, static, pre-initialized valfun structs are
> > the rule rather than the exception in this program, so having this
> > syntax for all of them seems.. well.. ugly :)
> > 
> 
>  Ah..   I see..
> 
>  (I don't think you need (uintptr_t) - you can cast a (const char *)
>   to a (char *) without having to go "through" that - I believe.)

E.. this was the whole point of this thread.  I *can't* cast
a (const char *) to a (char *) when using the -Wcast-qual gcc flag -
the -Wcast-qual flag produces exactly this type of warnings, to make
sure you don't treat const * pointers as normal pointers, and pass them
to functions that do stupid things like modify them or free them :)

>  Is this C, or C++.. there are some differences in the type of
>  a constant character string between the two...
> 
>  But - basically, what you are trying to describe is a field which
>  is sometimes 'const' and othertimes isn't... which doesn't make 
>  sense in the context of the C standard...  you'll need a cast
>  for the initialization, or some other approach besides static
>  initialization I believe... (or, just "live" with the warning...
>  which isn't pleasant at all.)

Well, I can't live with the warning with -Werror ;)  So I guess I'll
live with casting in free() :)

G'luck,
Peter

-- 
If wishes were fishes, the antecedent of this conditional would be true.

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

Re: free() and const warnings

[Thomas David Rivers]

> 
> On Fri, Jun 08, 2001 at 08:51:54AM -0400, Thomas David Rivers wrote:
> > > 
> > > GCC complains when I try to initialize the structure with something like:
> > > 
> > > struct validation_fun val_init[] = {
> > >   {"init",valfun_init,0}
> > > };
> > > 
> > > This can be avoided by:
> > > 
> > > struct validation_fun val_init[] = {
> > >   {(char *) (uintptr_t) "init",   valfun_init,0}
> > > };
> > > 
> > > ..but as a matter of fact, static, pre-initialized valfun structs are
> > > the rule rather than the exception in this program, so having this
> > > syntax for all of them seems.. well.. ugly :)
> > > 
> > 
> >  Ah..   I see..
> > 
> >  (I don't think you need (uintptr_t) - you can cast a (const char *)
> >   to a (char *) without having to go "through" that - I believe.)
> 
> E.. this was the whole point of this thread.  I *can't* cast
> a (const char *) to a (char *) when using the -Wcast-qual gcc flag -
> the -Wcast-qual flag produces exactly this type of warnings, to make
> sure you don't treat const * pointers as normal pointers, and pass them
> to functions that do stupid things like modify them or free them :)

 Yes - I see now... sorry for being slow on the "uptake" :-)

> 
> >  Is this C, or C++.. there are some differences in the type of
> >  a constant character string between the two...
> > 
> >  But - basically, what you are trying to describe is a field which
> >  is sometimes 'const' and othertimes isn't... which doesn't make 
> >  sense in the context of the C standard...  you'll need a cast
> >  for the initialization, or some other approach besides static
> >  initialization I believe... (or, just "live" with the warning...
> >  which isn't pleasant at all.)
> 
> Well, I can't live with the warning with -Werror ;)  So I guess I'll
> live with casting in free() :)

 It's not pretty either way... is it? 

- Dave R. -

--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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

Re: free() and const warnings

[Assar Westerlund]

Peter Pentchev <[EMAIL PROTECTED]> writes:
> GCC complains when I try to initialize the structure with something like:
> 
> struct validation_fun val_init[] = {
>   {"init",valfun_init,0}
> };
> 
> This can be avoided by:
> 
> struct validation_fun val_init[] = {
>   {(char *) (uintptr_t) "init",   valfun_init,0}
> };
> 
> ..but as a matter of fact, static, pre-initialized valfun structs are
> the rule rather than the exception in this program, so having this
> syntax for all of them seems.. well.. ugly :)

What version of gcc is this?  2.96?

All versions of 2.95.x that I've tried seems to eat the following
program with:

gcc -O -g -Werror -Wcast-qual -c foo.c

/assar

struct validation_fun {
const char  *name;
void*fun;
int dyn;
};

struct validation_fun   val_init[] = {
{"init",0,0}
};

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

Re: free() and const warnings

[Peter Pentchev]

On Fri, Jun 08, 2001 at 03:02:56PM +0200, Assar Westerlund wrote:
> Peter Pentchev <[EMAIL PROTECTED]> writes:
> > GCC complains when I try to initialize the structure with something like:
> > 
> > struct validation_fun   val_init[] = {
> > {"init",valfun_init,0}
> > };
> > 
> > This can be avoided by:
> > 
> > struct validation_fun   val_init[] = {
> > {(char *) (uintptr_t) "init",   valfun_init,0}
> > };
> > 
> > ..but as a matter of fact, static, pre-initialized valfun structs are
> > the rule rather than the exception in this program, so having this
> > syntax for all of them seems.. well.. ugly :)
> 
> What version of gcc is this?  2.96?
> 
> All versions of 2.95.x that I've tried seems to eat the following
> program with:
> 
> gcc -O -g -Werror -Wcast-qual -c foo.c
> 
> /assar
> 
> struct validation_fun {
> const char  *name;
> void*fun;
> int dyn;
> };
> 
> struct validation_fun   val_init[] = {
> {"init",0,0}
> };

My explanation was a reply to a suggestion to remove the 'const' in
the structure definition.

G'luck,
Peter

-- 
If I had finished this sentence,

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

Re: New error - lost data?

[Assar Westerlund]

"Deepak Jain" <[EMAIL PROTECTED]> writes:
> Others have seen this error (based on a Google search) but nothing recent
> and nothing that conclusive. This is a very standard config that has been
> stable for quite a while. The panic: malloc: lost data implies to me that
> something is misbehaving with its memory allocations.
> 
> Is this a hardware issue or an application problem? The kernel is 4.1
> RELEASE. The RAM is ECC.

It should not be an application problem.  It indicates that the memory
pool administered by the kernel malloc is corrupt.  Either it's a bug
in the kernel or bad memory.  Does it only happen on that particular
machine with that particular memory?

/assar

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

Re: free() and const warnings

[Assar Westerlund]

Peter Pentchev <[EMAIL PROTECTED]> writes:
> My explanation was a reply to a suggestion to remove the 'const' in
> the structure definition.

My fault.  The code that I should have shown was without the 'const'.
With gcc 2.95.3 and 'gcc -O -g -Werror -Wall -W -Wcast-qual -c foo.c'
I don't get any errors with the const-less program (below).  I was
wondering if this is something that has changed in recent gcc.

/assar

struct validation_fun {
char*name;
void*fun;
int dyn;
};

struct validation_fun   val_init[] = {
{"init",0,0}
};

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

Re: free() and const warnings

[Peter Pentchev]

On Fri, Jun 08, 2001 at 03:09:53PM +0200, Assar Westerlund wrote:
> Peter Pentchev <[EMAIL PROTECTED]> writes:
> > My explanation was a reply to a suggestion to remove the 'const' in
> > the structure definition.
> 
> My fault.  The code that I should have shown was without the 'const'.
> With gcc 2.95.3 and 'gcc -O -g -Werror -Wall -W -Wcast-qual -c foo.c'
> I don't get any errors with the const-less program (below).  I was
> wondering if this is something that has changed in recent gcc.

E d'oh, ok, my fault - it's not -Wcast-qual, it's -Wwrite-strings
that causes the problem :)  WARNS=2 in -current makes it go boom.

G'luck,
Peter

-- 
If this sentence didn't exist, somebody would have invented it.

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

Re: free() and const warnings

[T. William Wells]

> E.. this was the whole point of this thread.  I *can't* cast
> a (const char *) to a (char *) when using the -Wcast-qual gcc flag -

Not all -W options are equally useful and some are actively harmful.

This is one of them. There are several situations where it is
necessary to remove a qualifier (any code for strchr, e.g.).
Adding nonportable hacks to your code to avoid a gcc error message
is just plain bad coding.

Perhaps gcc has a way to turn off warnings temporarily; I haven't
checked lately. If not, roll your own. Define a comment like
/*CASTOK*/, to stick on each line with such a cast, then filter
the gcc output using a script that examines the source code for
such comments and removes the bogus error messages.

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

Re: How to disable software TCP checksumming?

[Julian Elischer]

Assar Westerlund wrote:
> 
> Ruslan Ermilov <[EMAIL PROTECTED]> writes:
> > On Fri, Jun 08, 2001 at 02:24:23PM +0200, Assar Westerlund wrote:
> > > Terry Lambert <[EMAIL PROTECTED]> writes:
> > > > This all came from IP headers being 14 bytes long, instead
> > > > of 16.
> > >
> > > Hu?  An IPv4 header (not including options) is 20 bytes long.
> > >
> > Terry meant the length of an IPv4 header up to but not including
> > the checksum field.

no he meant to say "ethernet header"



-- 
  __--_|\  Julian Elischer
 /   \ [EMAIL PROTECTED]
(   OZ) World tour 2000-2001
---> X_.---._/  
v

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

Re: problem with systm.h trying to call resettodr()

[Alexey V. Neyman]

On Fri, 8 Jun 2001, Peter Pentchev wrote:

>On Fri, Jun 08, 2001 at 01:49:12PM +0100, Rasputin wrote:
>You can only use kernel-space functions in kernel code, that is, writing
>a kernel module, or writing a piece of code that is to be compiled along
>with the rest in src/sys.

By the way, are there any underwater stones in linking userland programs
against libkern with '-static -nostdlib' to gcc?

Regards,
Alexey.



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

Re: How to disable software TCP checksumming?

[Bsdguru]

This thread is baffling. The bottom line is that you cant trust data coming 
into your machine, and you have to checksum it.  The link level check only 
verifies that what was sent by the last forwarding point is the same as what 
you got, but in NO WAY implies that all of the data is valid.  A link level 
checksum pass is a necessary, but not a sufficient condition for the data 
being acceptable. There are scads of reasons that it could be bad. Disabling 
checksumming is a kludge that you may chose to do, but its never the right 
thing to do.

bryan

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

Re: How to disable software TCP checksumming?

[Jonathan Lemon]

In article [EMAIL PROTECTED]> you write:
>This thread is baffling. The bottom line is that you cant trust data coming 
>into your machine, and you have to checksum it.  The link level check only 
>verifies that what was sent by the last forwarding point is the same as what 
>you got, but in NO WAY implies that all of the data is valid.  A link level 
>checksum pass is a necessary, but not a sufficient condition for the data 
>being acceptable. There are scads of reasons that it could be bad. Disabling 
>checksumming is a kludge that you may chose to do, but its never the right 
>thing to do.

I think there's some confusion here.  There are two types of checksums:

 1. CRC link-level checksum on the ethernet packet.
 2. Upper layer checksums (TCP/IP)

All hardware that I'm aware of automatically performs #1, I'm not sure
if there is anything that will permit disabling this.

Step 2 is usually known as the "end-to-end" checksum, and is traditionally 
performed by the host CPU.  Depending on your view of what constitutes
an "endpoint", these checksums may be performed by the network adapter
itself.  I believe that this is what the original meant by disabling 
software checksums, in the sense that his hardware would do this work.

Dispensing with TCP/IP checksum altogether is a fairly bad idea, but 
I don't think that is what was being proposed here.
-- 
Jonathan

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

Access to symbol table(including dynamics) at runtime

[Kevin Day]

Is there a simple way that I can lookup a symbol name(by address) during
runtime? 

I know I can exec nm, look up for the address I need, and get local
symbols, but it would be really nice if I could get addresses of functions
in dynamic libraries as well. I know I could use ldd to get offsets of each
.so and calculate from there, but I'm starting to think I'm reproducing work
that was done somewhere else.

If someone could point me at a man page to something that can do what I
need, tell me of a library that does something similar, or tell me why this
can't be done, i'd be very thankful. :)

-- 
Kevin Day
[EMAIL PROTECTED] - [EMAIL PROTECTED]

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

Re: Access to symbol table(including dynamics) at runtime

[Peter Pentchev]

On Fri, Jun 08, 2001 at 12:09:39PM -0500, Kevin Day wrote:
> 
> 
> Is there a simple way that I can lookup a symbol name(by address) during
> runtime? 
> 
> I know I can exec nm, look up for the address I need, and get local
> symbols, but it would be really nice if I could get addresses of functions
> in dynamic libraries as well. I know I could use ldd to get offsets of each
> .so and calculate from there, but I'm starting to think I'm reproducing work
> that was done somewhere else.
> 
> If someone could point me at a man page to something that can do what I
> need, tell me of a library that does something similar, or tell me why this
> can't be done, i'd be very thankful. :)

OK, you asked for it, here's a minimalistic answer: dlopen(3) :)

G'luck,
Peter

-- 
If wishes were fishes, the antecedent of this conditional would be true.

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

Re: Access to symbol table(including dynamics) at runtime

[Farooq Mela]

Kevin Day wrote:
> 
> Is there a simple way that I can lookup a symbol name(by address) during
> runtime?

man dlopen.

-- 
farooq <[EMAIL PROTECTED]>

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

Re: Access to symbol table(including dynamics) at runtime

[Dan Nelson]

In the last episode (Jun 08), Kevin Day said:
> Is there a simple way that I can lookup a symbol name(by address)
> during runtime?
> 
> I know I can exec nm, look up for the address I need, and get local
> symbols, but it would be really nice if I could get addresses of
> functions in dynamic libraries as well. I know I could use ldd to get
> offsets of each .so and calculate from there, but I'm starting to
> think I'm reproducing work that was done somewhere else.
> 
> If someone could point me at a man page to something that can do what
> I need, tell me of a library that does something similar, or tell me
> why this can't be done, i'd be very thankful. :)

Would dladdr() do what you want?

-- 
Dan Nelson
[EMAIL PROTECTED]

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

Re: Access to symbol table(including dynamics) at runtime

[Kevin Day]

> 
> Kevin Day wrote:
> > 
> > Is there a simple way that I can lookup a symbol name(by address) during
> > runtime?
> 
> man dlopen.
> 

I looked at this.. I see how I can dlopen my own executable, and dlsym()
will let me get addresses from symbol names, but how do I do the reverse? I
have an address and need to get the symbol name from it, not vice versa.



-- 
Kevin Day
[EMAIL PROTECTED] - [EMAIL PROTECTED]

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

sysKonnect dual gig adapter

[Bsdguru]

Looking at the description of the sysKonnect dual adapter, its not clear if 
this is a real 2 port nic or that the second port is only a failover port. I 
have 2 questions for anyone who has one:

1) Can this be used as a 2 port gigabit NIC?
2) Does this NIC have hardware failover (that is, when power is cut the 2 
ports will be physically tied together. I dont know of any PC plug in that 
does this, but its a neat feature.

Bryan

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

Re: Access to symbol table(including dynamics) at runtime

[Kevin Day]

> 
> In the last episode (Jun 08), Kevin Day said:
> > Is there a simple way that I can lookup a symbol name(by address)
> > during runtime?
> > 
> > I know I can exec nm, look up for the address I need, and get local
> > symbols, but it would be really nice if I could get addresses of
> > functions in dynamic libraries as well. I know I could use ldd to get
> > offsets of each .so and calculate from there, but I'm starting to
> > think I'm reproducing work that was done somewhere else.
> > 
> > If someone could point me at a man page to something that can do what
> > I need, tell me of a library that does something similar, or tell me
> > why this can't be done, i'd be very thankful. :)
> 
> Would dladdr() do what you want?


AHH! YES!

I'll buy a beer to the first person who adds dladdr(3) to the SEE ALSO
section of dlopen's man page.

Thank you!


-- 
Kevin Day
[EMAIL PROTECTED] - [EMAIL PROTECTED]

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

Re: Access to symbol table(including dynamics) at runtime

[Alfred Perlstein]

* Kevin Day <[EMAIL PROTECTED]> [010608 13:21] wrote:
> > 
> > In the last episode (Jun 08), Kevin Day said:
> > > Is there a simple way that I can lookup a symbol name(by address)
> > > during runtime?
> > > 
> > > I know I can exec nm, look up for the address I need, and get local
> > > symbols, but it would be really nice if I could get addresses of
> > > functions in dynamic libraries as well. I know I could use ldd to get
> > > offsets of each .so and calculate from there, but I'm starting to
> > > think I'm reproducing work that was done somewhere else.
> > > 
> > > If someone could point me at a man page to something that can do what
> > > I need, tell me of a library that does something similar, or tell me
> > > why this can't be done, i'd be very thankful. :)
> > 
> > Would dladdr() do what you want?
> 
> 
> AHH! YES!
> 
> I'll buy a beer to the first person who adds dladdr(3) to the SEE ALSO
> section of dlopen's man page.

If you want to be able to see symbols in your main executable you
_may_ need to also compile it with -export-dynamic or something
like that.

-- 
-Alfred Perlstein [[EMAIL PROTECTED]]
Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.

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

AW: sysKonnect dual gig adapter

[Heimes, Rene]

i can only answer question 1) - yes, it can be used as a dual port
gigabit nic
i can hardly imagine the syskonnect offers failover...

hth
cu

rené

-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Gesendet: Freitag, 8. Juni 2001 18:19
An: [EMAIL PROTECTED]
Betreff: sysKonnect dual gig adapter


Looking at the description of the sysKonnect dual adapter, its not clear
if 
this is a real 2 port nic or that the second port is only a failover
port. I 
have 2 questions for anyone who has one:

1) Can this be used as a 2 port gigabit NIC?
2) Does this NIC have hardware failover (that is, when power is cut the
2 
ports will be physically tied together. I dont know of any PC plug in
that 
does this, but its a neat feature.

Bryan

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

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

Re: sysKonnect dual gig adapter

[Brooks Davis]

On Fri, Jun 08, 2001 at 01:18:44PM -0400, [EMAIL PROTECTED] wrote:
> Looking at the description of the sysKonnect dual adapter, its not clear if 
> this is a real 2 port nic or that the second port is only a failover port. I 
> have 2 questions for anyone who has one:
> 
> 1) Can this be used as a 2 port gigabit NIC?
> 2) Does this NIC have hardware failover (that is, when power is cut the 2 
> ports will be physically tied together. I dont know of any PC plug in that 
> does this, but its a neat feature.

As the other respondent said, it's a 2-port NIC.  If you want failover,
you may want to check out Bill Paul's Fast EtherChannel module at:
http://people.freebsd.org/~wpaul/FEC/

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4

 PGP signature

Wide character support - wchar.h?

[Stefan Hoffmeister]

What are the status of / plans for support of select wide character
routines, such as the ones declared in wchar.h?

Particularly, I am looking for wcsoll, towupper, and towlower - IOW, the
whole barrage of wide character transformation and collation :-)

I haven't found anything conclusive in the mailing list archives.

Has anyone tried to "fake" support for these functions via iconv
operations from wide characters to the locale charset, performing a
"normal" toupper / tolower / strcoll, and then transforming back?

I am not certain whether these two transformations would be lossy or not.

TIA,
Stefan

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

Re: Wide character support - wchar.h?

[Peter Pentchev]

On Fri, Jun 08, 2001 at 07:51:08PM +0200, Stefan Hoffmeister wrote:
> 
> What are the status of / plans for support of select wide character
> routines, such as the ones declared in wchar.h?
> 
> Particularly, I am looking for wcsoll, towupper, and towlower - IOW, the
> whole barrage of wide character transformation and collation :-)
> 
> I haven't found anything conclusive in the mailing list archives.
> 
> Has anyone tried to "fake" support for these functions via iconv
> operations from wide characters to the locale charset, performing a
> "normal" toupper / tolower / strcoll, and then transforming back?
> 
> I am not certain whether these two transformations would be lossy or not.

I guess I should leave the answers to someone more familiar with this
than I am (next to none), but I do believe that Takuya SHIOZAKI
<[EMAIL PROTECTED]> is currently working on multibyte support
in -current's libc.

G'luck,
Peter

-- 
Do you think anybody has ever had *precisely this thought* before?

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

Re: free() and const warnings

[Mike Smith]

>  Since some strings are non-constant (the are allocated) - I believe
>  the `const' qualifier in the structure declaration is incorrect.

'const' just means "I will not be modifying this"; it's a way for a 
function prototype to constrain the function's implementation.

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E



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

ELF p_offset & p_vaddr

[milunovic]

-BEGIN PGP SIGNED MESSAGE-

I'm little confused.I'm reading ELF specification and I found that
p_offset and p_vaddr should be congrunet to module PAGE_SIZE.
So is this correct ? If it isn't can anybody tell me what is correct.
#define PAGE_SIZE 4096 
p_offset % PAGE_SIZE == p_vaddr % PAGE_SIZE 

Vojislav Milunovic
[EMAIL PROTECTED]

-BEGIN PGP SIGNATURE-
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQEVAwUBOyEaby3gPLld8IkLAQFB6Af/Y5jFvo4/YOLuawln6JBsavjG3AtxbxVd
gMMow39Jy1npYhmb+bzn7Dm2U4flhdlnLjF7j4Q02959uDH0qe1NHO665wu3dRoj
SjgzfV/sG/eO+0QDc5gVMQmvJUZLlDn4weThqlBzzrRusexxndOeiXC6VkQJI21z
eWKaB4cHSZ5QXIM3dCXyihNjEEMki9hLXwThtnd4jb83RRh6EWxkMsJn3lxJMSon
B8H482ldbUv2GK3hnfV2V7AaMqgcitcLpdkpNQTqrRtZkLXHjcFBSKYumhXwfX4g
cgTHJ01QTwQcdz2kd1Nlhfj017aZZK+iVYd57/13TEwfpZpT34Q5mg==
=wCU+
-END PGP SIGNATURE-



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

RE: New error - lost data?

[Deepak Jain]

Yes, its only happening on this one chassis so far. We'll try replacing the
memory and see what happens.

Thanks!

Deepak Jain
AiNET

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Assar Westerlund
Sent: Friday, June 08, 2001 9:07 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: New error - lost data?


"Deepak Jain" <[EMAIL PROTECTED]> writes:
> Others have seen this error (based on a Google search) but nothing recent
> and nothing that conclusive. This is a very standard config that has been
> stable for quite a while. The panic: malloc: lost data implies to me that
> something is misbehaving with its memory allocations.
>
> Is this a hardware issue or an application problem? The kernel is 4.1
> RELEASE. The RAM is ECC.

It should not be an application problem.  It indicates that the memory
pool administered by the kernel malloc is corrupt.  Either it's a bug
in the kernel or bad memory.  Does it only happen on that particular
machine with that particular memory?

/assar


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

Re: New error - lost data?

[Giorgos Keramidas]

On Fri, 8 Jun 2001, Deepak Jain wrote:

> I've never seen this error. Its been occuring randomly on this
> machine, sometimes as often as every few minutes, sometimes days
> apart.
>
> Others have seen this error (based on a Google search) but nothing recent
> and nothing that conclusive. This is a very standard config that has been
> stable for quite a while. The panic: malloc: lost data implies to me that
> something is misbehaving with its memory allocations.
>
> Is this a hardware issue or an application problem? The kernel is 4.1
> RELEASE. The RAM is ECC.

Well, this is definitely not an application problem.  Your kernel
panics before the malloc data for allocated/free memory is corrupt
somehow.  This seems to be a hardware problem.  Namely one of your
memory chips playing tricks on you.

I would start by removing a few RAM chips and seeing if this happens
when a particular set of them are being used.  If the problem persists
but only when a certain chip is present, you know whats wrong :)

-giorgos


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

Re: read(2) and ETIMEDOUT

[Bernd Walter]

On Thu, Jun 07, 2001 at 03:20:58PM -0700, Matt Dillon wrote:
> 
> :
> :On Thu, Jun 07, 2001 at 10:33:50AM -0700, Matt Dillon wrote:
> :> 
> :> :
> :> :Thanks, I will try setting errno, but I don't think it is signals.
> :> :I have been running truss on the process. The relevant part is
> :> :
> :> :gettimeofday(0xbfbffa54,0x0) = 0 (0x0)
> :> :select(0x50,0x93f8c90,0x0,0x0,0xbfbffa74)= 3 (0x3)
> :> :read(0x16,0xa2da000,0x8000)  ERR#60 'Operation timed out'
> :> :
> :> :In fact there are no signals in the whole truss output
> :> :
> :> :Graham.
> :> 
> :> What type of descriptor is the read being performed on?  A TCP
> :> connection or, say, a reading a file over NFS?  
> :
> :It is a TCP/IP connection.
> :
> :Graham.
> 
> You can get this if the TCP connection times out, either through a
> keepalive timeout or the protocol hits the maximum number of transmit
> retries.  I'd have to delve into the cvs logs to see when it was added,
> but it seems reasonable.  You should treat it simply as an EIO or
> something like that.

Keepalives are a good point.
I know of OS/2 Systems that can't handle them and behave the way you
describe.
What system is on the other side?

-- 
B.Walter  COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup   [EMAIL PROTECTED]


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

Re: read(2) and ETIMEDOUT

[Graham Barr]

On Fri, Jun 08, 2001 at 09:39:15PM +0200, Bernd Walter wrote:
> On Thu, Jun 07, 2001 at 03:20:58PM -0700, Matt Dillon wrote:
> > 
> > :
> > :On Thu, Jun 07, 2001 at 10:33:50AM -0700, Matt Dillon wrote:
> > :> 
> > :> :
> > :> :Thanks, I will try setting errno, but I don't think it is signals.
> > :> :I have been running truss on the process. The relevant part is
> > :> :
> > :> :gettimeofday(0xbfbffa54,0x0) = 0 (0x0)
> > :> :select(0x50,0x93f8c90,0x0,0x0,0xbfbffa74)= 3 (0x3)
> > :> :read(0x16,0xa2da000,0x8000)  ERR#60 'Operation timed out'
> > :> :
> > :> :In fact there are no signals in the whole truss output
> > :> :
> > :> :Graham.
> > :> 
> > :> What type of descriptor is the read being performed on?  A TCP
> > :> connection or, say, a reading a file over NFS?  
> > :
> > :It is a TCP/IP connection.
> > :
> > :Graham.
> > 
> > You can get this if the TCP connection times out, either through a
> > keepalive timeout or the protocol hits the maximum number of transmit
> > retries.  I'd have to delve into the cvs logs to see when it was added,
> > but it seems reasonable.  You should treat it simply as an EIO or
> > something like that.
> 
> Keepalives are a good point.
> I know of OS/2 Systems that can't handle them and behave the way you
> describe.
> What system is on the other side?

All the systems are exactly the same

Graham.

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

Re: sysKonnect dual gig adapter

[Bsdguru]

In a message dated 06/08/2001 1:28:22 PM Eastern Daylight Time, 
[EMAIL PROTECTED] writes:

> > 1) Can this be used as a 2 port gigabit NIC?
>  > 2) Does this NIC have hardware failover (that is, when power is cut the 
2 
>  > ports will be physically tied together. I dont know of any PC plug in 
that 
> 
>  > does this, but its a neat feature.
>  
>  As the other respondent said, it's a 2-port NIC.  If you want failover,
>  you may want to check out Bill Paul's Fast EtherChannel module at:
>  http://people.freebsd.org/~wpaul/FEC/

I specifically said "physical" failover. I guess no-one understands what that 
means? If  it was a feature of the card, there would be no driver support 
required. But thanks for the info.

Bryan

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

Re: sysKonnect dual gig adapter

[Peter Pentchev]

On Fri, Jun 08, 2001 at 03:55:55PM -0400, [EMAIL PROTECTED] wrote:
> In a message dated 06/08/2001 1:28:22 PM Eastern Daylight Time, 
> [EMAIL PROTECTED] writes:
> 
> > > 1) Can this be used as a 2 port gigabit NIC?
> >  > 2) Does this NIC have hardware failover (that is, when power is cut the 
> 2 
> >  > ports will be physically tied together. I dont know of any PC plug in 
> that 
> > 
> >  > does this, but its a neat feature.
> >  
> >  As the other respondent said, it's a 2-port NIC.  If you want failover,
> >  you may want to check out Bill Paul's Fast EtherChannel module at:
> >  http://people.freebsd.org/~wpaul/FEC/
> 
> I specifically said "physical" failover. I guess no-one understands what that 
> means? If  it was a feature of the card, there would be no driver support 
> required. But thanks for the info.

I have no idea whether this card-feature-no-driver statement is correct
in this particular case, but it is definitely not correct in general:
if it is a feature of the card, and especially if it is an advanced
feature of the card, you need driver support to enable it.

G'luck,
Peter

-- 
.siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI

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

Re: free() and const warnings

[Thomas David Rivers]

> 
> >  Since some strings are non-constant (the are allocated) - I believe
> >  the `const' qualifier in the structure declaration is incorrect.
> 
> 'const' just means "I will not be modifying this"; it's a way for a 
> function prototype to constrain the function's implementation.
> 

 Yes - it is..

 However,
  
  "a string"

 is a const array of char.

  malloc(9) 

 isn't. (And, can't be, since you have to, presumably,
 malloc the space and then write something meaningful
 to it...)

 So, if you declare a variable as

const char *

 and then have different "constness" in assigning to that data,
 you are asking for the one variable to be both `const' and non-`const'... 
 
 I was taking it from the "other side" (not the call to free() side, but
 the declaration of the data type...)  Saying that the datum isn't
 actually `const' - it's only "sometimes const" (and only during
 the static initialization.)   "sometimes const" doesn't make sense...

 But - then, if you remove the `const' - you get warnings from
 the initialization - assigning a pointer-to-const to a  pointer-to-non-const.

 So... what's a programmer to do?  That's the issue, right?

- Dave R. -

--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com




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

Re: Access to symbol table(including dynamics) at runtime

[Seth Kingsley]

On Fri, Jun 08, 2001 at 12:17:41PM -0500, Kevin Day wrote:
> I looked at this.. I see how I can dlopen my own executable, and dlsym()
> will let me get addresses from symbol names, but how do I do the reverse? I
> have an address and need to get the symbol name from it, not vice versa.

dladdr(3) of course. Not referenced in dlopen(3) either.

-- 
|| Seth Kingsley || Platforms Lab Opps || [EMAIL PROTECTED] ||

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

Re: New error - lost data?

[Munish Chopra]

On Fri, Jun 08, 2001 at 06:47:01PM +0300, Giorgos Keramidas wrote:
> On Fri, 8 Jun 2001, Deepak Jain wrote:
> 
> > Is this a hardware issue or an application problem? The kernel is 4.1
> > RELEASE. The RAM is ECC.
> 
> I would start by removing a few RAM chips and seeing if this happens
> when a particular set of them are being used.  If the problem persists
> but only when a certain chip is present, you know whats wrong :)

Check out http://reality.sgi.com/cbrady_denver/memtest86/ while you're
at it. I hear it's helped a lot of people find faulty RAM.

-- 
-Munish

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

Re: free() and const warnings

[Matt Dillon]

:OK, here's a scenario:
:
:struct validation_fun {
:   const char  *name;
:   valfun  *fun;
:   int dyn;
:};
:
:This is a structure for a set of validation functions, referenced by
:name from another type of object.  There are some predefined functions,
:present in the code at compile-time, and hardcoded in an array, with
:names given as "strings".  Thus, the 'const'.
:
:However, some of the functions may be defined at runtime, with both
:name and code sent by a server.  In that case, the name is a dynamically
:allocated char *, which needs to be freed upon cleanup.  So I have:
:
:[cleanup function]
:   ...
:   if (val->dyn)
:   free(val->name);
:
:Any suggestions on how to improve the design to avoid this, if possible,
:would be greatly welcome.
:
:G'luck,
:Peter

I am a great believer in const char * ... it's saved my ass on more
occassions then I can count.  I have very similar situations where
certain elements of a structure are usually static but sometimes dynamic.
My recommendation is that you NOT attempt to overload the duel nature
of 'name'.  Instead make it always a 'const char *'.

Here is my suggestion:

struct validation_fun {
const char  *name;
valfun  *fun;
int dyn;

/*
 * OPAQUE
 */
char*allocations;   /* or make it an array for more */
};

As far as 99.9% of your codebase is concerned, 'name' points to a
read-only entity and is not dynamically allocated, even from the
point of view of FreeValidationFun().  But if you need to dynamically
allocate the string for name you have a field to hold the dynamic
allocation, in this case 'allocations'.  You ALSO assign the result
to 'name', but FreeValidationFun() only looks to 'allocations' to
determine if there is anything it must free() and, of course,
'allocations' can remain NULL.

This neatly solves the problem and guarentees that no confusion will
occur.

Here's another example:  Lets say you have a routine that can return
an error code AND an error message, and to make it fast you want to
be able to return static strings for the message.  But sometimes the
error message is allocated.  So:

char *alloc = NULL;
const char *emsg;

error = TheRoutine1(parameters, &emsg, &alloc);
... process emsg ...
error = TheRoutine2(parameters, &emsg, &alloc);
... process emsg ...
error = TheRoutine3(parameters, &emsg, &alloc);
... process emsg ...
safe_free(&alloc);

TheRoutine*() assigns the error message simply with something like:

*emsg = "Yah, Everything is fine";

But if TheRoutine*() needs to allocate the error message it does
this:

safe_replacef(alloc, "You screwed up %d times!", n);
*emsg = alloc;

I have three helper routines to make this sort of string management
trivial:

void safe_free(char **ptr);

If *ptr is not NULL, free(*ptr) then set *ptr to NULL.

void safe_replace(char **ptr, const char *str);

If *ptr is not NULL, free(*ptr) then set *ptr = strdup(str);

void safe_replacef(char **ptr, const char *ctl, ...);

If *ptr is not NULL, free(*ptr) then use varargs and vasprintf()
to allocate the replacement string.

I call these routines 'safe' because if their internal malloc()s fail
they assert and exit... I don't like checking for memory failures
in thousands of places in my code, I prefer to check them in just a
handful of places.

Probably a more involved answer then you were looking for, but hey!

BTW, I don't use static buffers for virtually anything any more... I
use asprintf() (or in my case, safe_asprintf()), safe_strdup(), 
safe_replace(), safe_replacef(), safe_free(), etc...  My 'safe' routines.
I use them for everything these days.  It removes all possibilities of a
buffer overflow from my code.

-Matt


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

Re: free() and const warnings

[Matt Dillon]

Here is the whole set of supporting routines.

-Matt

/*
 * STRDUP.C
 *
 * $Backplane: backplane/src/libsupport/strdup.c,v 1.13 2001/04/03 00:03:18 dillon Exp 
$
 */

#include "defs.h"

Export char *safe_strdup(const char *s);
Export char *safe_strdup_segment(const char *start, const char *end);
Export char *safe_replace(char **pptr, const char *s);
Export char *safe_replacef(char **pptr, const char *ctl, ...);
Export char *safe_append(char **pptr, const char *s);
Export char *safe_appendf(char **pptr, const char *ctl, ...);

/*
 * safe_strdup() -  Safe version of strdup(), core dump if alloc fails
 */
char *
safe_strdup(const char *s)
{
char *r;

if (s == NULL)
return(NULL);
if ((r = strdup(s)) == NULL)
fatalmem();
return(r);
}

/*
 * safe_replace() - Free existing string, allocate copy
 *
 *  Allocates a copy of 's' and stores the copy in *pptr.  The
 *  previous contents of *ptr is freed.
 *
 *  Typical useage is to initialize *pptr to NULL, then use
 *  safe_replace() as many times as necessary (or within a loop),
 *  then safe_free(pptr) after all operations are complete.
 *
 *  This code optimizes the case where 's' is the same as *pptr.
 */
char *
safe_replace(char **pptr, const char *s)
{
/*
 * Same data (also occurs if s == *ptr), nothing to do
 */
if (*pptr) {
if (s && strcmp(s, *pptr) == 0)
return(*pptr);
free(*pptr);
}

/*
 * free old, dup new.
 */
*pptr = (s) ? strdup(s) : NULL;
return(*pptr);
}

/*
 * safe_replacef() -Free existing string, allocate copy, with formatting
 *
 *  This operates the same as safe_replace(), except a printf-style
 *  format string and arguments is passed rather then a simple string.
 */
char *
safe_replacef(char **pptr, const char *ctl, ...)
{
va_list va;
char *optr = *pptr;

if (ctl) {
va_start(va, ctl);
if (vasprintf(pptr, ctl, va) < 0)
fatalmem();
va_end(va);
}
safe_free(&optr);
return(*pptr);
}

/*
 * safe_append() -  Append to an existing string, reallocating as required
 *
 *  *pptr represents allocated storage or NULL.  *pptr is replaced 
 *  with a new string which is the original string with the 's' argument
 *  appended.  The original string is deallocated.
 *
 *  *pptr is usually initialized to NULL, causing this routine to do
 *  the initial allocation as well as the reallocation in successive
 *  calls.  safe_free(pptr) is typically called after all operations
 *  are complete and the result string is no longer needed.
 */
char *
safe_append(char **pptr, const char *s)
{
char *old;
char *new;

if ((old = *pptr) != NULL) {
int newLen = strlen(old) + strlen(s) + 1;
new = malloc(newLen);
snprintf(new, newLen, "%s%s", old, s);
free(old);
} else {
new = strdup(s);
}
*pptr = new;
return(new);
}

/*
 * safe_appendf() - Var-args version of safe_append()
 *
 *  Operates like safe_append(), but using a printf-like format string
 *  and additional arguments to generate the string to append.
 */
char *
safe_appendf(char **pptr, const char *ctl, ...)
{
char *old;
char *new;
va_list va;

va_start(va, ctl);
if ((old = *pptr) != NULL) {
if (vasprintf(&new, ctl, va) < 0)
DBASSERT(0);
*pptr = new;
asprintf(&new, "%s%s", old, new);
free(*pptr);
free(old);
} else {
if (vasprintf(&new, ctl, va) < 0)
DBASSERT(0);
}
va_end(va);
*pptr = new;
return(new);
}

/*
 * safe_strdup_segment() - duplicate a portion of a string
 *
 *  Returns an allocated string representing the specified segment
 *  between start and end (end non-inclusive).  Dumps core if the
 *  allocation fails.  The returned string will be null terminated.
 */
char *
safe_strdup_segment(const char *start, const char *end)
{
char *new;
int len;

if (start == NULL || end == NULL)
return(NULL);

if (start > end) {
const char *temp = end;
end = start;
start = temp;
}

len = end - start;
new = safe_malloc(len + 1);
memcpy(new, start, len);
new[len] = '\0';
return(new);
}

/*
 * ASPRINTF.C
 *
 * $Backplane: backplane/src/libsupport/asprintf.c,v 1.4 2001/04/03 00:03:18 dillon 
Exp $
 */

#include "defs.h"

Export void safe_asprintf(char **pptr, const char *ctl, ...);
Export void safe_vasprintf(char **pptr, const char *ctl, va_list va);

/*
 * safe_asprintf() -safe version of asprintf()
 *
 *  This routine implements a safe version of asprintf(), which allocates
 *  the result string and stored it in *ptr.  The program will dump
 *  core if the allocation fails.
 *
 *  *ptr need not be initialized to anything in particular prior to
 *  calling this rou

Re: free() and const warnings

[Matt Dillon]

Oh my, and just posting these I found a couple of bugs!

:char *
:safe_replace(char **pptr, const char *s)
:{
:/*
: * Same data (also occurs if s == *ptr), nothing to do
: */
:if (*pptr) {
:   if (s && strcmp(s, *pptr) == 0)
:   return(*pptr);
:   free(*pptr);
:}
:
:/*
: * free old, dup new.
: */
:*pptr = (s) ? strdup(s) : NULL;
:return(*pptr);
:}

Should call safe_strdup(), not strdup().


:char *
:safe_append(char **pptr, const char *s)
:{
:char *old;
:char *new;
:
:if ((old = *pptr) != NULL) {
:   int newLen = strlen(old) + strlen(s) + 1;
:   new = malloc(newLen);
:   snprintf(new, newLen, "%s%s", old, s);
:   free(old);
:} else {
:   new = strdup(s);
:}
:*pptr = new;
:return(new);
:}

Ditto.  Should call safe_strdup(), not strdup().

I probably should have cleaned the source up before posting it.  I
also have a fatalmem() routine which assert(0)'s, and DBASSERT(0)
is simply assert(0)...  really should be a fatalmem() call too.

Oh well.  You get the picture!

-Matt

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

Re: newbussifying drivers

[Sergey Babkin]

j mckitrick wrote:
> 
> Okay, there is something i'm not understanding here.  In the ed driver,
> there are many possible cards, which each have different i/o ports, correct?
> The driver has a lot of probe routines, and it looks like they are just
> using different macros with hard-coded (#defined) port addresses.
> 
> So, how do you CORRECTLY use the newbus calls to probe these ports?  I am
> not running -current, so i do not have 'hints'.

As Doug Rabson said, write an 'identify' routine. Look at the
ep driver for an example. And my artile in DaemonNews
(www.daemonnews.org) from I think August 2000 or somewhere around
that time gives some description of the newbussified ISA drivers.
It should also be included into the Handbook by now.

-SB

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

Re: ELF p_offset & p_vaddr

[John Polstra]

In article <[EMAIL PROTECTED]>,
milunovic  <[EMAIL PROTECTED]> wrote:
> 
> I'm little confused.I'm reading ELF specification and I found that
> p_offset and p_vaddr should be congrunet to module PAGE_SIZE.
> So is this correct ? If it isn't can anybody tell me what is correct.

It is correct.  It is done that way so that the file can be loaded
into memory simply by mapping it.  Mapping occurs on page boundaries.

> #define PAGE_SIZE 4096 
> p_offset % PAGE_SIZE == p_vaddr % PAGE_SIZE 

Yes, that's correct.  For example, notice that the final 3 digits are
the same here in the "VMA" and "File off" columns.  PAGE_SIZE == 4096
== 0x1000.

blake$ objdump -h /usr/bin/id

/usr/bin/id: file format elf32-i386

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
  0 .interp   0019  080480f4  080480f4  00f4  2**0
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .note.ABI-tag 0018  08048110  08048110  0110  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .hash 00d8  08048128  08048128  0128  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .dynsym   0230  08048200  08048200  0200  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .dynstr   0138  08048430  08048430  0430  2**0
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .rel.bss  0010  08048568  08048568  0568  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .rel.plt  0098  08048578  08048578  0578  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .init 000b  08048610  08048610  0610  2**2
  CONTENTS, ALLOC, LOAD, READONLY, CODE
  8 .plt  0140  0804861c  0804861c  061c  2**2
  CONTENTS, ALLOC, LOAD, READONLY, CODE
  9 .text 0928  0804875c  0804875c  075c  2**2
  CONTENTS, ALLOC, LOAD, READONLY, CODE
 10 .fini 0006  08049084  08049084  1084  2**2
  CONTENTS, ALLOC, LOAD, READONLY, CODE
 11 .rodata   035a  080490a0  080490a0  10a0  2**5
  CONTENTS, ALLOC, LOAD, READONLY, DATA
 12 .data 000c  0804a3fc  0804a3fc  13fc  2**2
  CONTENTS, ALLOC, LOAD, DATA
 13 .eh_frame 0004  0804a408  0804a408  1408  2**2
  CONTENTS, ALLOC, LOAD, DATA
 14 .ctors0008  0804a40c  0804a40c  140c  2**2
  CONTENTS, ALLOC, LOAD, DATA
 15 .dtors0008  0804a414  0804a414  1414  2**2
  CONTENTS, ALLOC, LOAD, DATA
 16 .got  0058  0804a41c  0804a41c  141c  2**2
  CONTENTS, ALLOC, LOAD, DATA
 17 .dynamic  0088  0804a474  0804a474  1474  2**2
  CONTENTS, ALLOC, LOAD, DATA
 18 .bss  0130  0804a4fc  0804a4fc  14fc  2**3
  ALLOC
 19 .comment  00c8      14fc  2**0
  CONTENTS, READONLY
 20 .note 0050      15c4  2**0
  CONTENTS, READONLY

John
-- 
  John Polstra   [EMAIL PROTECTED]
  John D. Polstra & Co., Inc.Seattle, Washington USA
  "Disappointment is a good sign of basic intelligence."  -- Chögyam Trungpa


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

Re: sysKonnect dual gig adapter

[Bill Paul]

> Looking at the description of the sysKonnect dual adapter, its not clear if 
> this is a real 2 port nic or that the second port is only a failover port. I 
> have 2 questions for anyone who has one:
> 
> 1) Can this be used as a 2 port gigabit NIC?

Yes. You will have two interfaces, sk0 and sk1, which represent the two
ports. Each interface operates independently of the other.

> 2) Does this NIC have hardware failover (that is, when power is cut the 2 
> ports will be physically tied together. I dont know of any PC plug in that 
> does this, but its a neat feature.

No. SysKonnect advertises the cards for use in failover applications
with their Windows (and Linux) drivers. However this is a feature of
their driver software only: it has nothing to do with the hardware.
When I wrote the if_sk driver, I decided that setting it up as a real
dual port NIC was more useful. (If you're really curious, go to
www.syskonnect.com and download their Linux driver source. It has all
of their failover magic in it.)

The SysKonnect cards consist of the SysKonnect GEnesis chip and the
XaQti XMAC II chip. (XaQti no longer exists, it was assimilated by
Vitesse.) The XMAC is a gigabit MAC with a generic bus interface. The
GEnesis provides the PCI interface, DMA support, some packet buffering
and arbitration. Basically, the GEnesis is what lets you connect the
XMAC to a PCI bus. But the GEnesis is designed to support _two_ XMAC
chips: it has two sets of DMA queues and two register windows so
you can twiddle both XMACs at once. That's how the dual link cards
work: there's one GEnesis and two XMACs, and if you have a copper
card, two Broadcom copper gigabit PHYs.

This is a bit different from the usual multiport NIC design where
you have two PCI-based MAC chips and a PCI-PCI bridge. Functionally,
this is the same as having a bunch of single-port PCI NICs in their
own slots. The SysKonnect multiplexes both MACs through a single
PCI slot instead.

-Bill

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

Re: newbussifying drivers

[Julian Elischer]

I don;t know why people always forget it, but also look 
at the sample driver in -current.
/usr/share/examples/drivers/make_device_driver.sh
(the 4.x version is way out of date)



On Fri, 8 Jun 2001, Sergey Babkin wrote:

> j mckitrick wrote:
> > 
> > Okay, there is something i'm not understanding here.  In the ed driver,
> > there are many possible cards, which each have different i/o ports, correct?
> > The driver has a lot of probe routines, and it looks like they are just
> > using different macros with hard-coded (#defined) port addresses.
> > 
> > So, how do you CORRECTLY use the newbus calls to probe these ports?  I am
> > not running -current, so i do not have 'hints'.
> 
> As Doug Rabson said, write an 'identify' routine. Look at the
> ep driver for an example. And my artile in DaemonNews
> (www.daemonnews.org) from I think August 2000 or somewhere around
> that time gives some description of the newbussified ISA drivers.
> It should also be included into the Handbook by now.
> 
> -SB
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 


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

Re: cloning network interfaces

[Brooks Davis]

Following Brian's suggestion, I've modified gif to create a /dev/if_gif
device with is controlled by the IOCIFMANAGE ioctl which allows creation
and deletion of specific devices and creation of wildcard devices.  I've
hacked ifconfig to support this in a general manner.  If you know which
one you want to use you can do something like

ifconfig gif783 10.0.0.1 10.0.0.2
# gifconfig has to come second because I didn't add creation support to
# it because I want to kill it off in favor of ifconfig "tsrc" and
# "tdst" parameters like Solaris uses.
gifconfig gif783 blah

or if you don't care which one you use you can do

newgif=`ifconfig gif#`
gifconfig ${newgif} blah 
ifconfig ${newgif} 10.0.0.1 10.0.0.2

You can also delete interfaces:

ifconfig -D gif783

Additionaly, I removed all the annoying refrences to gif.h and NGIF, and
moved things around so gif can be loaded and unloaded as a module.

A copy of the diff as avaiable at the URL below and I'm submitting a PR
titled "[PATCH] make gif fully dynamic".

http://www.one-eyed-alien.net/~brooks/FreeBSD/gif.diff

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4

 PGP signature

Re: Softupdates not syncing

[Doug Barton]

Chris Coleman wrote:
> 
> On one of our servers, deleted space is not being freed and causing is to
> run out of disk space.  To test this, I copied a 200 meg file to the /usr
> partition and then deleted it. I checked df before copying, after copying,
> and after deleting it.  After deleting it, the space never became
> available.  I waited atleast 24 hours just to make sure.
> 
> 4.2-STABLE FreeBSD 4.2-STABLE #0: Mon Jan 29 10:18:20 PST 2001

Please upgrade to 4.3-Stable and try your tests again. There is no way to
know whether or not your situation was improved by the many changes in
RELENG_4 in the last 4 months. 

Thanks,

Doug
-- 
If you're never wrong, you're not trying hard enough.

 Do YOU Yahoo!?

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