Re: portability sanity check
On Wed, Feb 21, 2001 at 09:56:08AM -0700, Warner Losh wrote: > There is some verbage in the structure layout part of the standard > that makes this a logical conclusion. > > However, it is overly tricky code. But then again to do the generic > sort of thing you want to do, you have to resort to C macros, or other > gross things to make it generic. The question becomes how do you do > that in the least gross way... Someone will say ``Use C++'' here. Then I will ignite a copy of `The Annotated C++ Reference Manual' and hit them with it. I think using unions is actually out of the question if you want to be able to allow new `types' after compile time. When you say ``resort to C macros,'' do you mean macros to hide the `type punning', or do you have something else in mind? Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Creating BSD bootable CD
Sergey Babkin wrote: > As far as I remember, there is not much special. Just create a > bootable floppy image and give it as option -b to mkhybrid. > (I strongly recommend mkhybrid over mkisofs because it tends to make > defective filesystems in fewer cases). I hadn't heard of mkhybrid, so investigated: it's been merged into mkisofs: ports/sysutils/mkisofs/work/mkisofs-1.13/ChangeLog.mkhybrid: Mon May 1 14:51:00 BST 2000 James Pearson <[EMAIL PROTECTED]> Version 1.13a01 mkhybrid has now been merged with, and is now part of mkisofs ports/sysutils/mkisofs/work/mkisofs-1.13/mkisofs/README.mkhybrid: mkhybrid v1.13 has now merged with, and is a part of mkisofs v1.13 Within a 4.2 CVS tree: ports/sysutils/mkhybrid is just an Attic structure cvs -R export -r HEAD mkhybrid cannot find module mkhybrid now features in ports/sysutils/mkisofs/ cvs -R export -r HEAD mkisofs ./pkg-plist:bin/mkhybrid man mkhybrid is an empty dummy (just a .so) Executables share same inode: 262201 -r-xr-xr-x 2 root wheel 374564 Feb 22 00:22 /usr/local/bin/mkhybrid 262201 -r-xr-xr-x 2 root wheel 374564 Feb 22 00:22 /usr/local/bin/mkisofs Julian - Julian Stacey Unix Consultant - Munich Germany http://bim.bsn.com/~jhs/ Considering Linux ? Try FreeBSD with 4500 packages ! Ihr Rauchen => mein allergischer Kopfschmerz ! Kau/Schnupftabak probieren ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: portability sanity check
On Wed, Feb 21, 2001 at 08:53:57AM -0700, Warner Losh wrote: > The standard requires that (void *) &foo == (void *) &foo->s Thanks, that is what I was trying to track down but couldn't find it. I also thought that perhaps a structure has the same requirement alignments as its first member ... I think that means the same thing as you've stated. Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: OpenSSH 2.5.1
On Wed, Feb 21, 2001 at 10:23:30AM +0900, Tomoyuki Murakami wrote: > --Repost--- > If duplicated, ignore this. thanks. > --- > Hi > > I have made a patch to up ssh version 2.3.0(FreeBSD-current) to > recently released OpenSSH 2.5.1. > Too rough made and it should have more measurements especially in, > > - SKEY or OPIE functions. > - Kerberos4/5 functions. > > I could not compile with -DSKEY and -DK... options yet. > > Patch file is too large(gziped 170k+ ;-)to attach here, so I put it in > > http://www.c-wind.com/~tomo/230-250.diff.gz > - /usr/src/crypto/openssh diffs > - MD5 (230-251.diff.gz) = 9ff326a90d1f0b6d2eb0f863defdc129 > > http://www.c-wind.com/~tomo/secure-251.tar.gz > - /usr/src/secure Makefiles > - MD5 (secure-251.tar.gz) = 7c23bc97fd1e8a48034509b2169dca91 I might be wrong, but I think that OpenSSH upgrades, just as upgrades for most software in src/contrib, are not handled with patches, but with imports on the vendor branch - then CVS examines the changes that the FreeBSD Project has made to the individual files, and tries to merge them into the newly imported version. Still, thanks for your time :) G'luck, Peter -- This sentence contains exactly threee erors. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: portability sanity check
On Wed, Feb 21, 2001 at 05:13:35PM +0100, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Warner Losh writes:
> >In message <[EMAIL PROTECTED]> "Jacques A. Vidrine" writes:
> >: Likewise if the first member were a more complex data type, but
> >: nevertheless the same between the different structures.
> >:
> >: It seems safe to me, but I can't explain why :-)
> >
> >It is obfuscated 'C', but it is safe. The standard requires that
> >(void *) &foo == (void *) &foo->s and that if s were a complex
> >structure that it be laid out the same in all instances of s. So I
> >think that it is "safe" to do that.
>
> Safe, but stupid, since type-safety is lost when doing so.
Type-safety is a cruch for the weak-minded.
:-)
But seriously I think that for the purpose of building a utility
function for use by qsort or similar, using a union just for such
a purpose is more obfuscated.
struct nothing_much_in_common_really {
const char *s;
union {
struct foo foo;
struct bar bar;
} u;
};
But if there is a better way, I'm all ears :-)
Cheers,
--
Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Bug in creating ICMP error messages in FreeBSD4.2
[redirected to -net]
On Wed, Feb 21, 2001 at 09:50:58AM +, [EMAIL PROTECTED] wrote:
> >On Mon, Feb 19, 2001 at 08:26:56PM +0100, mouss wrote:
> > > At 14:25 19/02/01 +0200, [EMAIL PROTECTED] wrote:
> > > > Hi,
> > > > I encountered the following problem in the 4.2 version.
> > > > In ip_forward, the following lines intend to save the mbuf in
> > > > case we want to send ICMP error later:
> > > > mcopy = m_copy(m, 0, imin((int)ip->ip_len, 64));
> > > > if (mcopy && (mcopy->m_flags & M_EXT))
> > > > m_copydata(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t));
> > > >
> > > > Later on, before sending the ICMP packet we do:
> > > > if (mcopy->m_flags & M_EXT)
> > > > m_copyback(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t));
> > > >
> > > > The problem as I understand it is that the m_copydata and m_copyback,
> > > > actually do nothing (It just copies from mcopy to itself).
> > >
> > > I'm speaking from memory, so don't take this for more than it is:)
> > >
> > > As far as I understand:
> > > m_copym copies the mbuf, but if there is external storage, only
> > > pointers are copied. so you get two mbuf chains with a common
> > > external storage.
> > > m_copydata will copy the external storage.
> > > that's why there are both m_copym and m_copydata. so while
> > >m_copydata(mcopy, (mcopy...))
> > > is surprising, it's not nothing. it copies the data pointed to
> > > in mcopy.
> > >
> > I wrote this code, and the above said is right.
>
> I understand that this is what you meant it to be.
> But look again at m_copydata.
> This is the relevant line:
>bcopy(mtod(m, caddr_t) + off, cp, count);
> If cp is mtod(m, caddr_t) and off is 0, this command has no effect.
>
> Anyway, even if I am wrong about this, the facts are that if you
> take FreeBSD 4.2-RELEASE machine, put net.inet.ip.forwarding to 1,
> and then blast the kernel with ip packets with len 256 and with
> destination to which it has a direct network route (on its local
> lan), but it can't resolve the arp entry the kernel crashes
> after a while. You can try this yourself. I can explain some more,
> and give exact conf' if anybody wants it.
>
> Now if you stop with a debugger in icmp_error you see that
> oip->ip_len equals 1, then you see the other stuff I talked about,
> and then you get a kernel panic.
>
> After you make the correction I suggested, and do the same thing,
> you see that oip->ip_len equals 256 (the right value), and you
> never get a kernel panic.
>
> I'll be glad to here other explanations to this kernel crash.
>
You are right, the code does nothing, though it was supposed to
preserve the byte order of IP header fields in case ip_output()
modifies them. The idea was to save the standard IP header in
some area in mbuf that is unused for M_EXT mbufs, but obviously
mtod() place is wrong, it points to the external data for M_EXT
mbuf. Could you please try this patch:
Index: ip_input.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v
retrieving revision 1.130.2.12
diff -u -p -r1.130.2.12 ip_input.c
--- ip_input.c 2001/02/01 20:25:09 1.130.2.12
+++ ip_input.c 2001/02/21 16:48:10
@@ -1513,7 +1513,8 @@ ip_forward(m, srcrt)
*/
mcopy = m_copy(m, 0, imin((int)ip->ip_len, 64));
if (mcopy && (mcopy->m_flags & M_EXT))
- m_copydata(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t));
+ m_copydata(mcopy, 0, sizeof(struct ip),
+ (caddr_t)(&mcopy->m_ext + 1));
#ifdef IPSTEALTH
if (!ipstealth) {
@@ -1661,7 +1662,8 @@ ip_forward(m, srcrt)
return;
}
if (mcopy->m_flags & M_EXT)
- m_copyback(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t));
+ m_copyback(mcopy, 0, sizeof(struct ip),
+ (caddr_t)(&mcopy->m_ext + 1));
icmp_error(mcopy, type, code, dest, destifp);
}
And if that does not work, this (more clear but slower) one:
Index: ip_input.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v
retrieving revision 1.130.2.13
diff -u -p -r1.130.2.13 ip_input.c
--- ip_input.c 2001/02/07 01:03:13 1.130.2.13
+++ ip_input.c 2001/02/21 16:10:35
@@ -1510,9 +1510,17 @@ ip_forward(m, srcrt)
* we need to generate an ICMP message to the src.
*/
mcopy = m_copy(m, 0, imin((int)ip->ip_len, 64));
- if (mcopy && (mcopy->m_flags & M_EXT))
- m_copydata(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t));
+ /*
+* Make sure the copy is read-write.
+*/
+ if (mcopy && (mcopy->m_flags & M_EXT)) {
+ struct mbuf *mtemp = mcopy;
+
+ mcopy = m_dup(mtemp, M_DONTWAIT);
+ m_freem(mtemp);
+ }
+
#ifdef IPSTEALTH
if (!ipstealth) {
#endif
@@ -1658,8 +1666,6 @@ ip_forward(m, srcrt)
Re: make bug? (dependency names with '$')
Warner Losh wrote: > This does sound like a bug in our make :-(. A quick update: This bug does not occur with NetBSD make. I spent a couple of hours diffing the sources (there are a lot more differences than I expected) to see if there was any one small patch that would make things work for FreeBSD, but I wasn't successful. There are many patches in NetBSD make that deal specifically with '$', but apparently just adding these is not sufficient. I would need to get below this superficial view to see what's going on. There is a person with login name "will" who made a CVS log entry that says: Assume MAINTAINER. I will be taking the job of merging NetBSD/OpenBSD improvements (including :C & :L, among others). After that, I'll be coming up with other ways to improve make(1). If he is still the make maintainer for FreeBSD, can someone give me a full email address for him? Thanks, Jason Jason Brazile [EMAIL PROTECTED] Netcetera AG, 8040 Zuerichphone +41 1 247 70 70 fax +41 1 247 70 75 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Listing configured md(4) devices
Hello phk and -hackers
With md(4)'s great autounit feature, it's becoming harder to keep
track of md(4) devices. Without autounit, you pretty much knew what
was what since you had to specify the unit number; with autounit,
things like `make release` configure an arbitrary unit without telling
you what it is, or even letting you change it (which isn't really
necessary).
jhb recently suggested that a way to get a list of active md(4)
devices and the way they were configured (size, type, etc.) would be a
nice remedy to the problem describe above (see "doFS.sh should obey
MDDEVICE if available" on -current a few weeks back).
I've come up with a relatively short patch to implement this. It adds
a new ioctl, MDIOCQUERY, to get information on a configured md(4)
device (it returns a filled in md_ioctl structure modulo md_file,
which, I think, can't be obtained without explicitly storing the path
during cofiguration (i.e., you can't derive a path from a vnode)), and
uses the 'kern.disks' sysctl to find out which devices are currently
configured. With it, `mdconfig -l` will list all devices and their
configurations, and `mdconfig -d -u ` will print information on the
device specified.
Comments? Suggestions?
Thanks
Dima Dorfman
[EMAIL PROTECTED]
Index: sys/dev/md/md.c
===
RCS file: /st/src/FreeBSD/src/sys/dev/md/md.c,v
retrieving revision 1.23
diff -u -r1.23 md.c
--- sys/dev/md/md.c 2001/01/28 20:55:55 1.23
+++ sys/dev/md/md.c 2001/02/21 08:27:08
@@ -829,6 +829,30 @@
default:
return (EOPNOTSUPP);
}
+ case MDIOCQUERY:
+ sc = mdfind(mdio->md_unit);
+ if (sc == NULL)
+ return (ENOENT);
+ mdio->md_type = sc->type;
+ mdio->md_options = sc->flags;
+ switch (sc->type) {
+ case MD_MALLOC:
+ mdio->md_size = sc->nsect;
+ break;
+ case MD_PRELOAD:
+ mdio->md_size = sc->nsect;
+ (u_char *)(uintptr_t)mdio->md_base = sc->pl_ptr;
+ break;
+ case MD_SWAP:
+ mdio->md_size = sc->nsect * (PAGE_SIZE / DEV_BSIZE);
+ break;
+ case MD_VNODE:
+ mdio->md_size = sc->nsect;
+ /* XXX fill this in */
+ mdio->md_file = NULL;
+ break;
+ }
+ return (0);
default:
return (ENOIOCTL);
};
Index: sys/sys/mdioctl.h
===
RCS file: /st/src/FreeBSD/src/sys/sys/mdioctl.h,v
retrieving revision 1.7
diff -u -r1.7 mdioctl.h
--- sys/sys/mdioctl.h 2001/01/01 23:08:26 1.7
+++ sys/sys/mdioctl.h 2001/02/21 08:27:08
@@ -75,6 +75,7 @@
#define MDIOCATTACH_IOWR('m', 0, struct md_ioctl) /* attach disk */
#define MDIOCDETACH_IOWR('m', 1, struct md_ioctl) /* detach disk */
+#define MDIOCQUERY _IOWR('m', 2, struct md_ioctl) /* query status */
#define MD_CLUSTER 0x01/* Don't cluster */
#define MD_RESERVE 0x02/* Pre-reserve swap */
Index: sbin/mdconfig/mdconfig.c
===
RCS file: /st/src/FreeBSD/src/sbin/mdconfig/mdconfig.c,v
retrieving revision 1.6
diff -u -r1.6 mdconfig.c
--- sbin/mdconfig/mdconfig.c2001/01/31 08:41:18 1.6
+++ sbin/mdconfig/mdconfig.c2001/02/21 08:27:08
@@ -19,7 +19,12 @@
#include
#include
#include
+#include
+int intcmp(const void *, const void *);
+int list(void);
+int query(const int);
+
struct md_ioctl mdio;
enum {UNSET, ATTACH, DETACH} action = UNSET;
@@ -30,6 +35,7 @@
fprintf(stderr, "Usage:\n");
fprintf(stderr, "\tmdconfig -a -t type [-o [no]option]... [ -f file] [-s size]
[-u unit]\n");
fprintf(stderr, "\tmdconfig -d -u unit\n");
+ fprintf(stderr, "\tmdconfig -l [-u unit]\n");
fprintf(stderr, "\t\ttype = {malloc, preload, vnode, swap}\n");
fprintf(stderr, "\t\toption = {cluster, compress, reserve, autounit}\n");
fprintf(stderr, "\t\tsize = %%d (512 byte blocks), %%dk (kB), %%dm (MB) or
%%dg (GB)\n");
@@ -41,10 +47,10 @@
{
int ch, fd, i;
char *p;
- int cmdline = 0;
+ int cmdline = 0, haveunit = 0;
for (;;) {
- ch = getopt(argc, argv, "ab:df:o:s:t:u:");
+ ch = getopt(argc, argv, "ab:df:lo:s:t:u:");
if (ch == -1)
break;
switch (ch) {
@@ -86,6 +92,11 @@
usage();
mdio.md_file = optarg;
break;
+ case 'l':
+
Re: portability sanity check
In message <[EMAIL PROTECTED]> "Jacques A. Vidrine" writes: : Likewise if the first member were a more complex data type, but : nevertheless the same between the different structures. : : It seems safe to me, but I can't explain why :-) It is obfuscated 'C', but it is safe. The standard requires that (void *) &foo == (void *) &foo->s and that if s were a complex structure that it be laid out the same in all instances of s. So I think that it is "safe" to do that. There are times that you'd want to do this (like generic list routines), but such type punning, as this is known, is error prone and can lead to problems. It is best avoided in favor of macros, unions or some other less error prone technique. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: make bug? (dependency names with '$')
At Thu, 22 Feb 2001 09:41:29 +0100, Jason Brazile wrote: > There is a person with login name "will" who made a CVS log entry that > says: > Assume MAINTAINER. I will be taking the job of merging > NetBSD/OpenBSD improvements (including :C & :L, among others). > After that, I'll be coming up with other ways to improve > make(1). > > If he is still the make maintainer for FreeBSD, can someone give me a > full email address for him? Try '[EMAIL PROTECTED]' :-) /Johan K To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Build timings - FreeBSD 4.2 vs. Linux
* Robin Cutshaw <[EMAIL PROTECTED]> [010221 06:07] wrote: > > OK, I set softupdates on the disk/partition that the build source/target > is on. It made no difference in timing. I then created a memory disk, > set softupdates on it, and mounted it as /tmp. AMAZINGLY, the build > went from 2:50 to 0:40, now much faster than the Linux system. I'm > going to do the ram disk thing on Linux and see if it makes a difference. What about just making sure that /tmp and /usr/tmp and /var/tmp are all softupdates enabled? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Build timings - FreeBSD 4.2 vs. Linux
Robin Cutshaw wrote: > On Mon, Feb 19, 2001 at 12:21:26PM -0800, Peter Wemm wrote: > > > > > > Any ideas as to why it would take almost three times longer to build > > > on FreeBSD? > > > > This is probably a silly question, but you did recompile the kernel for > > SMP, right? > > > > Actually, I was using the stock GENERIC UP kernel. I wanted to get a > baseline. OK, but this would have been a good thing to tell us to start with. :-) > > Have you tuned the FreeBSD kernel? It still ships with a worst-case > > configuration so that it runs optimally on i386 cpus. :-( Copy GENERIC > > to something else and remove all but 'cpu i686', rebuild and install. > > Also, get rid of 'sl', and 'ppp' from the kernel config as that messes > > up certain things (interrupt masks). Ideally, do a proper cleanup and > > configure it for your specific hardware (ie: remove all the other ethernet > > drivers, etc). > > > > There's a problem here. I tried to configure an SMP kernel but when it > booted the fxp0 (Compaq dual eepro100 adapter) got timeout errors and > wouldn't work. I went back and did the config/make on the GENERIC > kernel and booted it. Same thing. The stock GENERIC kernel that came > with the dist works just fine. Any ideas? > > One other problem I've seen with the Compaq 8500 system. FreeBSD doesn't > see the pci adapter on the secondary bus. I had to move the ethernet > adapter to the primary bus for it to work. Perhaps the output of 'pciconf -l' and mptable(8) would be useful. dmesg also, after a verbose boot (boot -v at the loader). > > A couple of possibilities.. If you want to compare the two side by side, > > try mounting the freebsd filesystems in async mode, just like linux does by > > default. In particular, make sure you get /tmp, /var/tmp and wherever your > > build is. > > > > OK, I set softupdates on the disk/partition that the build source/target > is on. It made no difference in timing. I then created a memory disk, > set softupdates on it, and mounted it as /tmp. AMAZINGLY, the build > went from 2:50 to 0:40, now much faster than the Linux system. I'm > going to do the ram disk thing on Linux and see if it makes a difference. Are you using the gcc -pipe option for the build? You should. Second, did you try a softupdates fs mounted on /tmp itself? I've found that it makes about the same difference as a ramdisk. gcc's -pipe largely makes that irrelevant though. > Once I figure out the fxp0 problem from above, I'll do a parallel build > and see what speedups occur. > > Thanks! > Robin > -- > > Robin Cutshaw internet: [EMAIL PROTECTED] [EMAIL PROTECTED] > Internet Labs, Inc. BellNet: 404-713-4000[EMAIL PROTECTED] > XFree86 coreteam/board member > > "Time is just one damn thing after another" -- PBS/Nova > > -- > Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: make bug? (dependency names with '$')
Kees Jan wrote: > Jason Brazile wrote: > > This bug does not occur with NetBSD make. I spent a couple of hours > > diffing the sources (there are a lot more differences than I expected) > > There was some talk on the OpenPackages list about differences in the makes > of the three BSD's. I've only followed the discussion with half an eye, but > it would be nice for them too to see the makes converge, or at least iron > out differences here and there. > > http://openpackages.org/pipermail/op-tech/ Thanks for the pointer. That is a very interesting site. For those who haven't heard of it, it is an effort to unify the various BSD (NetBSD, FreeBSD, OpenBSD, BSDi, Darwin) 3rd party software packaging so that all BSDs can use the same system. As a side effect of their wanting to remove effort duplication, they are trying to also unify the various flavors of BSD make. Jason Jason Brazile [EMAIL PROTECTED] Netcetera AG, 8040 Zuerichphone +41 1 247 70 70 fax +41 1 247 70 75 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: make bug? (dependency names with '$')
Dear All, > > This bug does not occur with NetBSD make. I spent a couple of hours > diffing the sources (there are a lot more differences than I expected) > There was some talk on the OpenPackages list about differences in the makes of the three BSD's. I've only followed the discussion with half an eye, but it would be nice for them too to see the makes converge, or at least iron out differences here and there. http://openpackages.org/pipermail/op-tech/ Kees Jan You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
warning in free():
Hi I am running a C program in user space on FreeBSD 3.3 release. I got a warning like this: testing in free(): warning: modified (chunk-) pointer. testing is the name of the executable I am running. Could anyone tell me what this warning means? What may be the effect of this code when I shift it to kernel with due modifications? I have put this code in kernel and when this gets executed, I get a panic immediately or some time later. This happens even if I don't execute any command after this code. When the kernel reboots, it reports file system inconsistencies and goes into single user mode. When I do 'fsck' and reboot it, it gets rebooted to multi-user mode. I am totally lost. Any help in this regard will be appreciated. thanks and regards Madhavi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: warning in free():
* Madhavi Suram <[EMAIL PROTECTED]> [010222 05:09] wrote: > > Hi > > I am running a C program in user space on FreeBSD 3.3 release. I got a > warning like this: > > testing in free(): warning: modified (chunk-) pointer. > > testing is the name of the executable I am running. > > Could anyone tell me what this warning means? What may be the effect of > this code when I shift it to kernel with due modifications? It means you've most likely corrupted your malloc pool, meaning you've written past/before the edge of an allocation you've done. To fix it start being mor careful with pointers and checking array bounds. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: warning in free():
In message <[EMAIL PROTECTED]>, Madhavi S uram writes: > >Hi > >I am running a C program in user space on FreeBSD 3.3 release. I got a >warning like this: > > testing in free(): warning: modified (chunk-) pointer. > >testing is the name of the executable I am running. > >Could anyone tell me what this warning means? What may be the effect of >this code when I shift it to kernel with due modifications? It means that you do something like this: ... p = malloc(n); /* N <=2048 */ p += m; free(p); -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: warning in free():
Also, if you do something like:
void *ptr = malloc(size);
...
ptr++;
free() will complain about it.
Make sure you are not modifying ptr after it has been malloc()ed.
On 22-Feb-01 Alfred Perlstein wrote:
> * Madhavi Suram <[EMAIL PROTECTED]> [010222 05:09] wrote:
>>
>> Hi
>>
>> I am running a C program in user space on FreeBSD 3.3 release. I got a
>> warning like this:
>>
>> testing in free(): warning: modified (chunk-) pointer.
>>
>> testing is the name of the executable I am running.
>>
>> Could anyone tell me what this warning means? What may be the effect
>> of
>> this code when I shift it to kernel with due modifications?
>
> It means you've most likely corrupted your malloc pool, meaning you've
> written past/before the edge of an allocation you've done.
>
> To fix it start being mor careful with pointers and checking array
> bounds.
>
>
> --
> -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
--
*
("`-''-/").___..--''"`-._ (\ Dimmy the Wild UA1ACZ
`6_ 6 ) `-. ( ).`-.__.`) Enterprise Information Sys
(_Y_.)' ._ ) `._ `. ``-..-' Nevsky prospekt, 20 / 44
_..`--'_..-_/ /--'_.' ,' Saint Petersburg, Russia
(il),-'' (li),' ((!.-' +7 (812) 3148860, 5585314
*
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Compaq e500, 3com cardbus card help
I cant figure out to get freebsd 4.2 to recognize and enable my 3com cardbus card? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Compaq e500, 3com cardbus card help
On Thu, Feb 22, 2001 at 10:32:13AM -0500, Justin McKnight wrote: > I cant figure out to get freebsd 4.2 to recognize > and enable my 3com cardbus card? FreeBSD currently doesn't support cardbus cards. -- Simon Dick [EMAIL PROTECTED] "Why do I get this urge to go bowling everytime I see Tux?" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: warning in free():
Now having free() write to stdout/stderr isn't necessarily a good thing
for daemons. If the message goes through a socket, it'll be hard to
debug, which was the original intent.
I suggest having some way so that when a program becomes a daemon,
it can set some "silent-libc" or "libc messages go to logs" instead of
using stdout/stderr.
Wouldn't it not be cool if err() and warn() had the capability of using syslog
instead of a file or std* when needed. err_set_file allows one to use a file
instead. How about allowing the use of syslog?
At 16:16 22/02/01 +0300, Dmitry Dicky wrote:
>Also, if you do something like:
>
> void *ptr = malloc(size);
>
>...
> ptr++;
>
>free() will complain about it.
>Make sure you are not modifying ptr after it has been malloc()ed.
>
>
>On 22-Feb-01 Alfred Perlstein wrote:
> > * Madhavi Suram <[EMAIL PROTECTED]> [010222 05:09] wrote:
> >>
> >> Hi
> >>
> >> I am running a C program in user space on FreeBSD 3.3 release. I got a
> >> warning like this:
> >>
> >> testing in free(): warning: modified (chunk-) pointer.
> >>
> >> testing is the name of the executable I am running.
> >>
> >> Could anyone tell me what this warning means? What may be the effect
> >> of
> >> this code when I shift it to kernel with due modifications?
> >
> > It means you've most likely corrupted your malloc pool, meaning you've
> > written past/before the edge of an allocation you've done.
> >
> > To fix it start being mor careful with pointers and checking array
> > bounds.
> >
> >
> > --
> > -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-hackers" in the body of the message
>
>--
>*
>("`-''-/").___..--''"`-._ (\ Dimmy the Wild UA1ACZ
> `6_ 6 ) `-. ( ).`-.__.`) Enterprise Information Sys
> (_Y_.)' ._ ) `._ `. ``-..-' Nevsky prospekt, 20 / 44
> _..`--'_..-_/ /--'_.' ,' Saint Petersburg, Russia
> (il),-'' (li),' ((!.-' +7 (812) 3148860, 5585314
>*
>
>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: Build timings - FreeBSD 4.2 vs. Linux
Robin Cutshaw wrote: > > On Mon, Feb 19, 2001 at 12:21:26PM -0800, Peter Wemm wrote: > > > > > > Any ideas as to why it would take almost three times longer to build > > > on FreeBSD? > > > > This is probably a silly question, but you did recompile the kernel for > > SMP, right? > > > > Actually, I was using the stock GENERIC UP kernel. I wanted to get a > baseline. > > > Have you tuned the FreeBSD kernel? It still ships with a worst-case > > configuration so that it runs optimally on i386 cpus. :-( Copy GENERIC > > to something else and remove all but 'cpu i686', rebuild and install. > > Also, get rid of 'sl', and 'ppp' from the kernel config as that messes > > up certain things (interrupt masks). Ideally, do a proper cleanup and > > configure it for your specific hardware (ie: remove all the other ethernet > > drivers, etc). > > > > There's a problem here. I tried to configure an SMP kernel but when it > booted the fxp0 (Compaq dual eepro100 adapter) got timeout errors and > wouldn't work. I went back and did the config/make on the GENERIC > kernel and booted it. Same thing. The stock GENERIC kernel that came > with the dist works just fine. Any ideas? > > One other problem I've seen with the Compaq 8500 system. FreeBSD doesn't > see the pci adapter on the secondary bus. I had to move the ethernet > adapter to the primary bus for it to work. > > > > > A couple of possibilities.. If you want to compare the two side by side, > > try mounting the freebsd filesystems in async mode, just like linux does by > > default. In particular, make sure you get /tmp, /var/tmp and wherever your > > build is. > > > > OK, I set softupdates on the disk/partition that the build source/target > is on. It made no difference in timing. I then created a memory disk, > set softupdates on it, and mounted it as /tmp. soft updates is pointless on a ram disk. but it makes a huge difference if /tmp is on disk. > AMAZINGLY, the build > went from 2:50 to 0:40, now much faster than the Linux system. I'm > going to do the ram disk thing on Linux and see if it makes a difference. turn soft updtes off again on it.. it is just wasting CPU cycles. > > Once I figure out the fxp0 problem from above, I'll do a parallel build > and see what speedups occur. > > Thanks! > Robin > -- > > Robin Cutshaw internet: [EMAIL PROTECTED] [EMAIL PROTECTED] > Internet Labs, Inc. BellNet: 404-713-4000[EMAIL PROTECTED] > XFree86 coreteam/board member > > "Time is just one damn thing after another" -- PBS/Nova > > -- > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ 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: warning in free():
On Thu, 22 Feb 2001, mouss wrote: > Now having free() write to stdout/stderr isn't necessarily a good thing > for daemons. If the message goes through a socket, it'll be hard to > debug, which was the original intent. > > I suggest having some way so that when a program becomes a daemon, > it can set some "silent-libc" or "libc messages go to logs" instead of > using stdout/stderr. > > Wouldn't it not be cool if err() and warn() had the capability of using syslog > instead of a file or std* when needed. err_set_file allows one to use a file > instead. How about allowing the use of syslog? Open AF_UNIX socket to syslogd and then use err_set_file() to redirect all err/warn messages to syslogd instead of stdin/stdout. That should help you debug daemons. Best Regards To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Compaq e500, 3com cardbus card help
FreeBSD supports cardbus in -CURRENT, but I wouldn't expect it to ever support cardbus in 4.x. If you are daring you can get -CURRENT, but from what I hear right now, it's not working very well. = | Kenneth Culver | FreeBSD: The best NT upgrade| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = On Thu, 22 Feb 2001 [EMAIL PROTECTED] wrote: > On Thu, Feb 22, 2001 at 10:32:13AM -0500, Justin McKnight wrote: > > I cant figure out to get freebsd 4.2 to recognize > > and enable my 3com cardbus card? > > FreeBSD currently doesn't support cardbus cards. > > -- > Simon Dick[EMAIL PROTECTED] > "Why do I get this urge to go bowling everytime I see Tux?" > > 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
IOmega ZIP problem
Hi I'm using 4.2-RELEASE, with a parallel port ZIP drive (100M). Whenever I copy a large file from the zip drive (for example /dev/da0s1), the "cp" process eats 98% of the system resources. What's behind all this? Is there a way to fix it? 711 root 54 0 280K 168K RUN 0:45 93.87% 93.21% cp A 'renice' won't help. -- Thanks in advance, Torbjorn Kristoffersen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: warning in free():
At 18:37 22/02/01 +0200, diman wrote: >Open AF_UNIX socket to syslogd and then use err_set_file() >to redirect all err/warn messages to syslogd instead of >stdin/stdout. That should help you debug daemons. I agree, but one of the nice things about syslog interface is that it hides all the socket/device stuff. so getting back to the socket api is somewhat unsatisfactory. Also, I think having this directly in err() and warn() and friends would be more elegant. and this doesn't seem hard to do. something like using a function pointer to use fprintf or syslog, and an additionnal void* to use either err_file or syslog priority. Does this sound ok or is it an unuseful complication of code? cheers, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IOmega ZIP problem
On Thu, Feb 22, 2001 at 07:40:16PM +0100, Torbjorn Kristoffersen scribbled: | Hi I'm using 4.2-RELEASE, with a parallel port ZIP drive (100M). | Whenever I copy a large file from the zip drive (for example /dev/da0s1), | the "cp" process eats 98% of the system resources. What's behind all this? | Is there a way to fix it? | | 711 root 54 0 280K 168K RUN 0:45 93.87% 93.21% cp | | A 'renice' won't help. That's natural with "parallel". No way around it. -- +--+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Listing configured md(4) devices
The only comments I really had on this were:
1) Your comment about vnode->name mapping is correct, there is no way to
turn a vnode pointer into an absolute path meaningful to the caller. There
are countless reasons why believing this is possible is a bad idea, and we
keep having to hit people with sticks to remind them that this is the
case. :-)
2) I'm not sure I like the strncmp(.., "md", 2) stuff, as that means that
it would also match any other device name that might begin with md, which
potentially might not be provided by the md driver. This is currently (I
suspect) hypothetical as we don't have any other drivers beginning with
md, but it would be nice not to preclude that in the future. Restricting
all possible disk device names to two letters, of which the second is
always d, is not a scalable approach. That said, writing an easy matching
function without that assumption probably isn't all that easy, either.
Don't know what the right answer is, so I'm just saying I'm not sure I
like it, not saying, change it. :-)
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
On Thu, 22 Feb 2001, Dima Dorfman wrote:
> Hello phk and -hackers
>
> With md(4)'s great autounit feature, it's becoming harder to keep
> track of md(4) devices. Without autounit, you pretty much knew what
> was what since you had to specify the unit number; with autounit,
> things like `make release` configure an arbitrary unit without telling
> you what it is, or even letting you change it (which isn't really
> necessary).
>
> jhb recently suggested that a way to get a list of active md(4)
> devices and the way they were configured (size, type, etc.) would be a
> nice remedy to the problem describe above (see "doFS.sh should obey
> MDDEVICE if available" on -current a few weeks back).
>
> I've come up with a relatively short patch to implement this. It adds
> a new ioctl, MDIOCQUERY, to get information on a configured md(4)
> device (it returns a filled in md_ioctl structure modulo md_file,
> which, I think, can't be obtained without explicitly storing the path
> during cofiguration (i.e., you can't derive a path from a vnode)), and
> uses the 'kern.disks' sysctl to find out which devices are currently
> configured. With it, `mdconfig -l` will list all devices and their
> configurations, and `mdconfig -d -u ` will print information on the
> device specified.
>
> Comments? Suggestions?
>
> Thanks
>
> Dima Dorfman
> [EMAIL PROTECTED]
>
>
> Index: sys/dev/md/md.c
> ===
> RCS file: /st/src/FreeBSD/src/sys/dev/md/md.c,v
> retrieving revision 1.23
> diff -u -r1.23 md.c
> --- sys/dev/md/md.c 2001/01/28 20:55:55 1.23
> +++ sys/dev/md/md.c 2001/02/21 08:27:08
> @@ -829,6 +829,30 @@
> default:
> return (EOPNOTSUPP);
> }
> + case MDIOCQUERY:
> + sc = mdfind(mdio->md_unit);
> + if (sc == NULL)
> + return (ENOENT);
> + mdio->md_type = sc->type;
> + mdio->md_options = sc->flags;
> + switch (sc->type) {
> + case MD_MALLOC:
> + mdio->md_size = sc->nsect;
> + break;
> + case MD_PRELOAD:
> + mdio->md_size = sc->nsect;
> + (u_char *)(uintptr_t)mdio->md_base = sc->pl_ptr;
> + break;
> + case MD_SWAP:
> + mdio->md_size = sc->nsect * (PAGE_SIZE / DEV_BSIZE);
> + break;
> + case MD_VNODE:
> + mdio->md_size = sc->nsect;
> + /* XXX fill this in */
> + mdio->md_file = NULL;
> + break;
> + }
> + return (0);
> default:
> return (ENOIOCTL);
> };
> Index: sys/sys/mdioctl.h
> ===
> RCS file: /st/src/FreeBSD/src/sys/sys/mdioctl.h,v
> retrieving revision 1.7
> diff -u -r1.7 mdioctl.h
> --- sys/sys/mdioctl.h 2001/01/01 23:08:26 1.7
> +++ sys/sys/mdioctl.h 2001/02/21 08:27:08
> @@ -75,6 +75,7 @@
>
> #define MDIOCATTACH _IOWR('m', 0, struct md_ioctl) /* attach disk */
> #define MDIOCDETACH _IOWR('m', 1, struct md_ioctl) /* detach disk */
> +#define MDIOCQUERY _IOWR('m', 2, struct md_ioctl) /* query status */
>
> #define MD_CLUSTER 0x01/* Don't cluster */
> #define MD_RESERVE 0x02/* Pre-reserve swap */
> Index: sbin/mdconfig/mdconfig.c
> ===
> RCS file: /st/src/FreeBSD/src/sbin/mdconfig/mdconfig.c,v
> retrieving revision 1.6
> diff -u -r1.6 mdconfig.c
> --- sbin/mdconfig/mdconfig.c 2001/01/31 08:41:18 1.6
> +++ sbin/mdconfig/md
detecting a closing socket from a Lex/Yacc interpreter ?
Hello, I'm currently writing a small interpreter for a client/server application. the Lex and Yacc files seem to be OK, as the tests are running fine (as long as there is only one client, and the client dos not close its socket ...) I still have one problem : the server has a single thread : the process accept()s a connection, then processes the commands (with yyparse()), and after the current client disconnects, gets back to listening to the socket, and so on. the problem is that the yyparse() function does not return when the socket is closed. I've had a look at the sources of ftpd, where yacc is used, but from what I've seen, the yylex() function has been hand written (which I would like not to do) I've added a <> target in the lex file, but it does not seem to detect the socket close() taker for any solution, TfH -- Thierry Herbelot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: detecting a closing socket from a Lex/Yacc interpreter ?
I'm assuming right now you are just setting yyin to the fd for the socket. What you're gonna want to do is define the macro YY_INPUT (see the man page for details) so that it calls recv on your socket. and then if it errors you can have YY_INPUT return as an EOF and your <> rule will work fine. On Thu, Feb 22, 2001 at 09:32:42PM +0100, Thierry Herbelot wrote: > Hello, > > I'm currently writing a small interpreter for a client/server > application. > > the Lex and Yacc files seem to be OK, as the tests are running fine (as > long as there is only one client, and the client dos not close its > socket ...) > > I still have one problem : the server has a single thread : the process > accept()s a connection, then processes the commands (with yyparse()), > and after the current client disconnects, gets back to listening to the > socket, and so on. > > the problem is that the yyparse() function does not return when the > socket is closed. I've had a look at the sources of ftpd, where yacc is > used, but from what I've seen, the yylex() function has been hand > written (which I would like not to do) > > I've added a <> target in the lex file, but it does not seem to > detect the socket close() > > taker for any solution, > > TfH > -- > Thierry Herbelot > > 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
gdb and debugging Linux binaries
I have a question on how to debug Linux binaries. I have a core file from the linux binary, but if I use the FreeBSD gdb, it cannot find the shared libraries in /compat/linux/ If I use the /compat/linux/ /usr/bin/gdb, it says the core file is in the wrong format: Couldn't fetch registers from core file: File in wrong format Couldn't fetch register set 2 from core file: File in wrong format So what is the correct procedure for debugging Linux binaries? - JimP -- --- @(#) $Id: dot.signature,v 1.9 2000/07/10 16:43:05 pirzyk Exp $ __o [EMAIL PROTECTED] - _'\<,_ Senior Systems Engineer, Walt Disney Feature Animation (*)/ (*) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: warning in free():
In message <[EMAIL PROTECTED]>, mouss writes: >Now having free() write to stdout/stderr isn't necessarily a good thing >for daemons. If the message goes through a socket, it'll be hard to >debug, which was the original intent. > >I suggest having some way so that when a program becomes a daemon, >it can set some "silent-libc" or "libc messages go to logs" instead of >using stdout/stderr. Since some time ago, there is an API to control how the messages from malloc is output, look for "malloc_message" in malloc(3). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Bug in creating ICMP error messages in FreeBSD4.2
>[redirected to -net]
>
>On Wed, Feb 21, 2001 at 09:50:58AM +, [EMAIL PROTECTED] wrote:
>> >On Mon, Feb 19, 2001 at 08:26:56PM +0100, mouss wrote:
>> > > At 14:25 19/02/01 +0200, [EMAIL PROTECTED] wrote:
>> > > > Hi,
>> > > > I encountered the following problem in the 4.2 version.
>> > > > In ip_forward, the following lines intend to save the mbuf in
>> > > > case we want to send ICMP error later:
>> > > > mcopy = m_copy(m, 0, imin((int)ip->ip_len, 64));
>> > > > if (mcopy && (mcopy->m_flags & M_EXT))
>> > > > m_copydata(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t));
>> > > >
>> > > > Later on, before sending the ICMP packet we do:
>> > > > if (mcopy->m_flags & M_EXT)
>> > > > m_copyback(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t));
>> > > >
>> > > > The problem as I understand it is that the m_copydata and m_copyback,
>> > > > actually do nothing (It just copies from mcopy to itself).
>>
>You are right, the code does nothing, though it was supposed to
>preserve the byte order of IP header fields in case ip_output()
>modifies them. The idea was to save the standard IP header in
>some area in mbuf that is unused for M_EXT mbufs, but obviously
>mtod() place is wrong, it points to the external data for M_EXT
>mbuf. Could you please try this patch:
>
>Index: ip_input.c
>===
>RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v
>retrieving revision 1.130.2.12
>diff -u -p -r1.130.2.12 ip_input.c
>--- ip_input.c 2001/02/01 20:25:09 1.130.2.12
>+++ ip_input.c 2001/02/21 16:48:10
>@@ -1513,7 +1513,8 @@ ip_forward(m, srcrt)
> */
> mcopy = m_copy(m, 0, imin((int)ip->ip_len, 64));
> if (mcopy && (mcopy->m_flags & M_EXT))
>- m_copydata(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t));
>+ m_copydata(mcopy, 0, sizeof(struct ip),
>+ (caddr_t)(&mcopy->m_ext + 1));
>
> #ifdef IPSTEALTH
> if (!ipstealth) {
>@@ -1661,7 +1662,8 @@ ip_forward(m, srcrt)
> return;
> }
> if (mcopy->m_flags & M_EXT)
>- m_copyback(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t));
>+ m_copyback(mcopy, 0, sizeof(struct ip),
>+ (caddr_t)(&mcopy->m_ext + 1));
> icmp_error(mcopy, type, code, dest, destifp);
> }
>
>And if that does not work, this (more clear but slower) one:
>
>Index: ip_input.c
>===
>RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v
>retrieving revision 1.130.2.13
>diff -u -p -r1.130.2.13 ip_input.c
>--- ip_input.c 2001/02/07 01:03:13 1.130.2.13
>+++ ip_input.c 2001/02/21 16:10:35
>@@ -1510,9 +1510,17 @@ ip_forward(m, srcrt)
> * we need to generate an ICMP message to the src.
> */
> mcopy = m_copy(m, 0, imin((int)ip->ip_len, 64));
>- if (mcopy && (mcopy->m_flags & M_EXT))
>- m_copydata(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t));
>
>+ /*
>+ * Make sure the copy is read-write.
>+ */
>+ if (mcopy && (mcopy->m_flags & M_EXT)) {
>+ struct mbuf *mtemp = mcopy;
>+
>+ mcopy = m_dup(mtemp, M_DONTWAIT);
>+ m_freem(mtemp);
>+ }
>+
> #ifdef IPSTEALTH
> if (!ipstealth) {
> #endif
>@@ -1658,8 +1666,6 @@ ip_forward(m, srcrt)
> m_freem(mcopy);
> return;
> }
>- if (mcopy->m_flags & M_EXT)
>- m_copyback(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t));
> icmp_error(mcopy, type, code, dest, destifp);
> }
>
>
>Cheers,
>--
>Ruslan Ermilov Oracle Developer/DBA,
>[EMAIL PROTECTED] Sunbay Software AG,
>[EMAIL PROTECTED] FreeBSD committer,
>+380.652.512.251 Simferopol, Ukraine
>
>http://www.FreeBSD.org The Power To Serve
>http://www.oracle.com Enabling The Information Age
The first one works (I guess the second one also). Its nice trick.
If you could just add a line or two of remarks it would be great.
something like:
/* saving ip header for future use because ip_output might change it */
Thanks, Ido
_
Get Your Free Virus Protection Tool at http://www.VCatch.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Listing configured md(4) devices
> 2) I'm not sure I like the strncmp(.., "md", 2) stuff, as that means that
> it would also match any other device name that might begin with md, which
> potentially might not be provided by the md driver. This is currently (I
> suspect) hypothetical as we don't have any other drivers beginning with
> md, but it would be nice not to preclude that in the future. Restricting
> all possible disk device names to two letters, of which the second is
> always d, is not a scalable approach. That said, writing an easy matching
> function without that assumption probably isn't all that easy, either.
Assuming that a device name must consist of letters (which I suspect
is the case), it's fairly trivial; just check that what follows 'md'
is a number.
Here's a patch against what I sent in previously to do that. The
original with this included can be found at
http://www.unixfreak.org/~dima/home/md-list3.diff.
Thanks again
Dima Dorfman
[EMAIL PROTECTED]
--- mdconfig.c.o2 Thu Feb 21 05:27:00 2001
+++ mdconfig.c Thu Feb 22 16:32:34 2001
@@ -195,7 +195,7 @@
int
list(void)
{
- char *disklist, *p, *p2;
+ char *disklist, *p, *p2, *p3;
int dll;/* disklist length */
int mds[512], *mdsp, mdsc, i;
@@ -211,7 +211,9 @@
if (strncmp(p2, "md", 2) != 0)
continue;
p2 += 2;
- *mdsp = strtoul(p2, NULL, 10);
+ *mdsp = strtoul(p2, &p3, 10);
+ if (p2 == p3)
+ continue;
mdsc++;
if (++mdsp >= &mds[sizeof(mds)])
break;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Wake on Lan
Can somebody clue me in on how Wake On Lan is supposed to work? Does it require any support at all from the OS, or is it totally a BIOS thing? I've built the wake-on-lan program submitted via http://www.FreeBSD.org/cgi/query-pr.cgi?pr=23151 and, although it seems to work to bring W2K box out of suspend mode, what I'd really like to do is to be able to "shutdown -p now" a box and then boot it up remotely. Is this even supposed to be possible? I've tried to power on the following types of machines without success: Dell Optiplex GX110 (i810) (onboard 3c905C) Dell PowerEdge 4400 (onboard fxp) SuperMicro 370DER (oboard fxp) In all cases, I've enabled the PME or "remote wakeup" in the bios. Does FreeBSD need to do something on the way down to make this work? Thanks, Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Setting memory allocators for library functions.
Hi,
Usually when I write programs, I have functions such as the following:
void *
xmalloc(size_t size)
{
void *p;
if ((p=malloc(size))==NULL) {
fprintf(stderr, "out of memory\n");
exit(1);
}
return(p);
}
void *
xrealloc(void *ptr, size_t size)
{
void *p;
if ((p=realloc(ptr,size))==NULL) {
fprintf(stderr, "out of memory\n");
exit(1);
}
return(p);
}
And then I use these instead of malloc and realloc throughout the
program, and never have to worry about return values. Sometimes these
functions also have additional cleanup they perform. Anyway, there are
certain libc functions which also use malloc, such as getaddrinfo,
vasprintf, etc. These may fail with errno = ENOMEM. In general, it is
annoying to have to check the return values for these functions too.
Would it not be convenient to set the memory allocator used by certain
functions inside libc? I.E, be able to write:
set_allocator(xmalloc);
set_reallocator(xrealloc);
>From then on, one would never have to worry about the functions running
out of memory. I know that wrappers for functions which allocate memory
can also be written, but I feel that my proposal would is in general a
more convenient solution.
How do you guys feel about this?
-Farooq
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting memory allocators for library functions.
In message <[EMAIL PROTECTED]>, Farooq Mela writes: >How do you guys feel about this? It is a mistake to believe that you "don't have to worry about running out of memory". You should always check, every time, and exit as gracefully as you can. -s To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Windows 2000 pro & FreeBSD
i need help dual booting win200 and freebsd4.2. Win200 is already installed casue i wanted to use its bootmanager for loading each OS. I know win2k and load openbsd so figure i wont have any trouble dual booting with freebsd. Now I cant find any documentation on dual booting win2k and freebsd. I need help! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting memory allocators for library functions.
Peter Seebach wrote:
> It is a mistake to believe that you "don't have to worry about running
> out of memory". You should always check, every time, and exit as gracefully
> as you can.
>
> -s
Of course I realize that allocating memory can fail. That is why I use
xmalloc and friends - so that I can avoid having to check for failure
each time I want to allocate memory. I don't believe you understand what
I am proposing. Consider the following inside libc:
void *(*libc_malloc)(size_t)=malloc;
void *(*libc_calloc)(size_t, size_t)=calloc;
void *(*libc_realloc)(void *, size_t)=realloc;
void
set_allocator(void *(*func)(size_t))
{
libc_malloc=func;
}
/* Same type of functions for calloc and realloc.. */
Now, consider some other function that is part of libc, such as
getaddrinfo. Say it does the following:
/* code ... */
foo=malloc(128);
if (foo==NULL) {
/* do clean-up.. */
errno=ENOMEM;
return(NULL);
}
This would be replaced by:
foo=(*libc_malloc)(128);
if (foo=NULL) {
/* do clean-up */
errno=ENOMEM;
return(NULL);
}
It will still have to check for the allocation failing. But if this were
to be done, an application which installs its own allocators will not
have to worry about anything inside libc running out of memory, and will
not have to handle that error condition. Furthermore, inside the
user-defined allocator (xmalloc etc), other types of cleanup can be
handled if the real malloc() returns NULL. (Atexit can only do so much.)
Hope this clears it up.
-Farooq
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting memory allocators for library functions.
In message <[EMAIL PROTECTED]>, Farooq Mela writes: >Of course I realize that allocating memory can fail. That is why I use >xmalloc and friends - so that I can avoid having to check for failure >each time I want to allocate memory. That's the problem. You still *NEED* to check. You can't just exit; you have to figure out what you have open, and close it. You have to figure out what files you may have been halfway through writing, and make sure that you aren't about to leave a critical file half-written, with the only copy of the rest of the data somewhere in memory. It is very, very, rarely correct to say "oops, no memory, I will quit immediately without saving any work". Imagine a word processor with this behavior. No attempt to save your file, no nothing, it just suddenly closes all windows and dies. There are very few programs where it is acceptable to abort just because you ran out of memory. >I don't believe you understand what >I am proposing. I do, lots of programs do it. It's a bad idea. You really still do have to check, because in almost all cases, there will be stuff you should do on your way down, beyond just "exit". >It will still have to check for the allocation failing. But if this were >to be done, an application which installs its own allocators will not >have to worry about anything inside libc running out of memory, and will >not have to handle that error condition. Of course it will! It can't guarantee that the memory is available, and it can't guarantee that it cleans up properly, because "proper cleanup" may vary from one place to another. >Furthermore, inside the >user-defined allocator (xmalloc etc), other types of cleanup can be >handled if the real malloc() returns NULL. (Atexit can only do so much.) Exactly. Atexit *can't do enough*. Each individual place where you do something that *could* fail must be checked, and the failure handled correctly *for that place*. You can't short-cut this; if you do, your code will inevitably fail in the most inconvenient possible way, because computers are ornery. Yes, it's a lot of work checking for every single error that could occur, and handling it in a graceful fashion. However, it is *MUCH* better for, say, gethostbyname to set errno to ENOMEM and return a null pointer, than for gethostbyname to ritually suicide the entire program. The allocator which spews an error and dies is almost always an incorrect allocator. There may be counterexamples, but they're rare, and since all of the relevant library functions can probably fail *FOR OTHER REASONS*, you still have to check all the return values and handle them yourself. Even if you can prove that getaddrinfo can never fail because malloc failed, it can still fail for other reasons. You still have to check for it failing. "Fixing" the allocator doesn't remove the need to check the return of every function that can fail. -s To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IOmega ZIP problem
On Thu, Feb 22, 2001 at 01:19:33PM -0600, Michael C . Wu wrote: > On Thu, Feb 22, 2001 at 07:40:16PM +0100, Torbjorn Kristoffersen scribbled: > | Hi I'm using 4.2-RELEASE, with a parallel port ZIP drive (100M). > | Whenever I copy a large file from the zip drive (for example /dev/da0s1), > | the "cp" process eats 98% of the system resources. What's behind all this? > | Is there a way to fix it? > | > | 711 root 54 0 280K 168K RUN 0:45 93.87% 93.21% cp > | > | A 'renice' won't help. > > > That's natural with "parallel". No way around it. To clarify a bit, parallel port hardware depends on the system processor doing all the data transfers, every single byte, and spending even more time checking if it's time for the next byte to go. There's no DMA, there's not even a controller you can tell 'here's a 512-byte block, let it fly'. There's no way around it indeed. G'luck, Peter -- This would easier understand fewer had omitted. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting memory allocators for library functions.
Peter Seebach wrote: > > In message <[EMAIL PROTECTED]>, Farooq Mela writes: > >Of course I realize that allocating memory can fail. That is why I use > >xmalloc and friends - so that I can avoid having to check for failure > >each time I want to allocate memory. > > That's the problem. You still *NEED* to check. You can't just exit; you > have to figure out what you have open, and close it. You have to figure > out what files you may have been halfway through writing, and make sure that > you aren't about to leave a critical file half-written, with the only copy > of the rest of the data somewhere in memory. > > It is very, very, rarely correct to say "oops, no memory, I will quit > immediately without saving any work". > This is not what I am arguing. I gave a simple example of an xmalloc function which does just print an error and exit. However, I've written many large applications using this sort of scheme where when allocation fails, all sorts of cleanup is performed before the process exits (cleaning up & restoring terminal mode, gracefully closing files / sockets / etc, syslogging the event, etc). It is hardly ever a simple exit as soon as allocation fails. [snip] > There are very few programs where it is acceptable to abort just because > you ran out of memory. > > >I don't believe you understand what > >I am proposing. > > I do, lots of programs do it. It's a bad idea. You really still do have > to check, because in almost all cases, there will be stuff you should do > on your way down, beyond just "exit". > > >It will still have to check for the allocation failing. But if this were > >to be done, an application which installs its own allocators will not > >have to worry about anything inside libc running out of memory, and will > >not have to handle that error condition. > > Of course it will! It can't guarantee that the memory is available, and > it can't guarantee that it cleans up properly, because "proper cleanup" may > vary from one place to another. What I mean here is that the *application* will not have to handle that error condition. It will be handled by the the malloc wrapper(s). > > >Furthermore, inside the > >user-defined allocator (xmalloc etc), other types of cleanup can be > >handled if the real malloc() returns NULL. (Atexit can only do so much.) > > Exactly. Atexit *can't do enough*. > > Each individual place where you do something that *could* fail must be > checked, and the failure handled correctly *for that place*. > > You can't short-cut this; if you do, your code will inevitably fail in > the most inconvenient possible way, because computers are ornery. > > Yes, it's a lot of work checking for every single error that could occur, > and handling it in a graceful fashion. However, it is *MUCH* better > for, say, gethostbyname to set errno to ENOMEM and return a null pointer, > than for gethostbyname to ritually suicide the entire program. > > The allocator which spews an error and dies is almost always an incorrect > allocator. There may be counterexamples, but they're rare, and since all > of the relevant library functions can probably fail *FOR OTHER REASONS*, > you still have to check all the return values and handle them yourself. Yes, but you would not have to write code which checks for ENOMEM. I will bet that the error handling code you write for getcwd giving ENOENT is very different from the code which handles ENOMEM from getcwd. I never write programs in which I must check the return value of each and every call to malloc/realloc/etc. It would be a lot of repetitive code. That is exactly why I use malloc wrappers, which then do all the required cleanup if allocation fails. It is actually a very effective system if done correctly, and makes life easier for me at least ;-). I would rather not have to check the return value from something like memory allocation, which is done very often in programs, and in todays VM systems, doesnt fail until all swap space is consumed. > > Even if you can prove that getaddrinfo can never fail because malloc failed, > it can still fail for other reasons. You still have to check for it failing. > "Fixing" the allocator doesn't remove the need to check the return of every > function that can fail. Indeed. Getaddrinfo is an example of a function that can fail for other reasons. But something such as asprintf or getcwd, etc, it is annoying to have to write code which will perform the cleanup that a malloc wrapper would otherwise execute. I just believe it would be a convenience to programmers if this system could be implemented. If someone prefers not to use it, and check each return value, that is fine; they are not required to use it. -Farooq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Windows 2000 pro & FreeBSD
The trick is to get the windows 2000 bootloader load the boot0 program like it would DOS. Pretend you have Dos on your hard disk and instead of linking the boot option to command.com, link it to the boot0. This means, of course, that you have to copy the boot0 file to your Windows partition. Works like a charm on my machine. Jan On Fri, 23 Feb 2001, Justin McKnight wrote: > i need help dual booting win200 and freebsd4.2. Win200 is already installed > casue i wanted to use its bootmanager for loading each OS. I know win2k and > load openbsd so figure i wont have any trouble dual booting with freebsd. > Now I cant find any documentation on dual booting win2k and freebsd. I need > help! > > > 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
