Kent Boortz <[EMAIL PROTECTED]> writes:
> If application A do a write like
>
> write(socket, buf, 100);
>
> and application B read this like
>
> read(socket, buf, 100);
>
> without checking the result from the read operation, then this code
> will probably work 99.% of the time. But if
Sheldon Hearn <[EMAIL PROTECTED]> writes:
> How on earth is one supposed to shut up the -Wconversion warnings
> generated for all the functions that take mode_t arguments?
>
> I've tried every sane typecast I can think of to prove to the compiler
> that I know what I'm doing, but it won't shut up
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> What about under solaris UFS?
Yes, it does update the atime.
And most Unixes seem to do the same thing.
/assar
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Terry Lambert <[EMAIL PROTECTED]> writes:
> Flags are associated with inodes, and symlinks do not have
> inodes in the common case, as they exist solely in the
> directory entry, unless they are too long.
Hu? The contents of the link will be stored in the inode itself
rather than in data blocks
Sheldon Hearn <[EMAIL PROTECTED]> writes:
> static inline void
> xdaemonwarn(char *fmt, ...)
> {
> va_list ap;
>
> va_start(ap, fmt);
> if (!daemon_quiet)
> warn(fmt, ap);
> va_end(ap);
>
> return;
> }
>
> GCC gives "syntax error before 'void'". Fair
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
"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 w
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 *)
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.
> >
> >
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
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 s
Daniel Hemmerich <[EMAIL PROTECTED]> writes:
> Any comments, suggestions, swears concerning adding a new function,
> strndup(), to libc?
See src/crypto/heimdal/lib/roken/strndup.c :-)
> char *
> strndup(str, max_len)
> const char *str;
> size_t max_len;
> {
> size_t len;
Gordon Tetlow <[EMAIL PROTECTED]> writes:
> BTW, is this still valid? From /etc/defaults/make.conf:
>
> # Kerberos 5
> # If you want KerberosIV (KTH Heimdal), define this:
> # ** WARNING **
> # ** WARNING ** This is very experimental at this stage. If you
> # ** WARNING ** need stable Kerberos5,
"Jacques A. Vidrine" <[EMAIL PROTECTED]> writes:
> Will we always have this dichotomy between kblah/k5blah utilities? It is
> fairly annoying. Anecdotally, there don't seem to be many new Kerberos
> IV installations, & Kerberos V's utilities can get/list/trash version 4
> & 5 tickets.
Yes. My
ecureuil <[EMAIL PROTECTED]> writes:
> Hi
Hello.
> I'm trying to get interfaces' list and infos with getifaddrs().
> The ifa_data struct should contain all needed information, but
> this is a NULL pointer for IPv4 interfaces. Why ?
What you are printing is the link level address and the v4 add
Will Andrews <[EMAIL PROTECTED]> writes:
> So from general consensus, people who desire this functionality can get
> it from ports/devel/pmake and the (non-functional) -DREMOTE code can be
> nuked from make(1).
I was under the impression that not much development happened on
(distributed) pmake,
Will Andrews <[EMAIL PROTECTED]> writes:
> So, I'm wondering who uses it, and what purpose it serves. There is
> nothing in the manpage about this "feature".
I believe these are left-overs from the customs support that pmake
(aka 4.4BSD make) used to have a long time ago.
You might want to look
Matt Dillon <[EMAIL PROTECTED]> writes:
> I need something gdb can latch on to. If the program exits all the state
> required to debug the problem goes away.
abort() doesn't exit, it sends a SIGABRT which is caught by gdb.
/assar
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "un
[EMAIL PROTECTED] (Peter Seebach) writes:
> Okay, from a style standpoint, the basic problem is that this function
> is a mistake.
No, I use a function like that (called emalloc) all the time, when I
know there's nothing better to do than exit.
> Programs may have temp files open, they may have
Aled Morris <[EMAIL PROTECTED]> writes:
> On Mon, 18 Dec 2000, Matt Dillon wrote:
>
> >void *
> >safe_malloc(int bytes)
> >{
> > void *ptr;
> >
> > if ((ptr = malloc(bytes)) == NULL)
> > *(int *)0 = 1; /* force seg fault */
>
>
> Shouldn't you use "kill(0, SIGS
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> This is useless for a commercial product for obvious reasons.
>
> I'm looking for something freely available.
Perhaps ftp://athena-dist.mit.edu/pub/ATHENA/ares/ares-1.1.0.tar.gz is
useful? It comes with an MIT-style license.
/assar
To Unsubscrib
I wrote:
> Please try the following patch. It will get comitted when my
> buildworld has completed (successfully).
And my buildworld suceeded so the patch has been comitted as version
1.8.2.3
/assar
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body
Mike Silbersack <[EMAIL PROTECTED]> writes:
> Ok, the problem seems to be that the new version of compile_et which was
> MFC'd is creating broken header files, it just happens that libfetch is
> the first part of the buildworld that hits it.
Please try the following patch. It will get comitted w
Marius Bendiksen <[EMAIL PROTECTED]> writes:
> In the following code, from /sys/kern/vfs_bio.c : bread(), it appears to
> me that it is possible for a null pointer to be deferenced?
>
> struct buf *bp;
>
> bp = getblk(vp, blkno, size, 0, 0);
> *bpp = bp;
>
> /* i
Warner Losh <[EMAIL PROTECTED]> writes:
> : Anyways, (and it's really orthogonal) having a generated vnode_if.h
> : (in /sys/kern or /usr/include/sys) makes it easier for the developer
> : of third-party file systems (i.e. me :-), by not having to figure out
> : how to generate vnode_if.h from vno
Warner Losh <[EMAIL PROTECTED]> writes:
> Yes. They must be compiled against the kernel, just like modules
> provided by freebsd.
Even if I knew that the files in /usr/include/sys/* correspond with
the kernel?
Anyways, (and it's really orthogonal) having a generated vnode_if.h
(in /sys/kern or
Warner Losh <[EMAIL PROTECTED]> writes:
> Hmmm. I've always found that the kernel only files need to be
> compiled with a kernel installed. This included loadable modules.
What about third-party loadable modules?
> Bruce and I have been working out a patch to make it possible to
> compile load
Warner Losh <[EMAIL PROTECTED]> writes:
> There are also other generated files in the tree. syscalls.c is
> another example that is generated once, and then committed to the
> tree.
Talking about this, was there any opinions on what to do with
vnode_if.h? (See my PR kern/17613). I do think tha
Robert Watson <[EMAIL PROTECTED]> writes:
> with the advent of IPv6, I'm not sure what the approved mechanism
> is.
int inet_pton(int af, const char *src, void *dst);
See rfc2553.
/assar
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the
Don Lewis <[EMAIL PROTECTED]> writes:
> I thought about using this, but it doesn't appear to be easy to track
> changes to an official branch. I was looking for something that would
> be as easy tracking changes made by infrequent imports on the vendor
> branch.
No, it's just a hack. Having hie
Brooks Davis <[EMAIL PROTECTED]> writes:
> Yup, just use cvsup to maintain an up to date copy of the repository
> localy and then cvs checkout your source tree from there. This allows
> you to keep in sync and keep local modifications in your tree. Updates
> take longer and I recommend updating
Aaron Smith <[EMAIL PROTECTED]> writes:
> i've done some searching and i've seen discussion of userland fs
> before. has there been any progress in the user-space filesystem area? i
> have a nifty project and i would like to avoid using loopback NFS; have we
> got anything akin to linux's userfs y
Jonas Bülow <[EMAIL PROTECTED]> writes:
> Hi,
Hej.
> What is the easiest way to install FreeBSD-current?
Grab floopies and install over FTP from current.freebsd.org. And then
run cvsup if you want to update to even more current code.
> Before I ran into trouble I want to ask if 4.0 supports t
Hi, in PR kern/15452 I have sent in patches to make getfh always be in
the system call table. Details are also included in the PR. Any
thoughts/comments/flames?
/assar
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Randell Jesup <[EMAIL PROTECTED]> writes:
> Sure, depending on what's in a vnode (I haven't looked).
Note that I was comparing the `pointers' and not the contents. The
way the VFS works you only keep one vnode for every file.
> That's what I was thinking of, partially. It makes bin
Randell Jesup <[EMAIL PROTECTED]> writes:
> Sounds like what we'd want to build it upon. If the FS doesn't
> support it, use st_dev/st_ino.
Actually, since it's in the kernel, the default implementation of the
vnode operation might be:
int
vop_default_cmp (struct vnode *v1, struct vnode *
Garance A Drosihn <[EMAIL PROTECTED]> writes:
> In the case of AFS, I think you'd want to expand the size of st_dev.
> All files in an AFS volume are "one device", I would think. If the
> "device" is gone (ie, the volume is not mounted), then all files in
> that "device" (volume) will not be avai
Anthony Kimball <[EMAIL PROTECTED]> writes:
> What is the closest approximation to a Solaris door call in FreeBSD?
Create a unix socket and send messages over that.
/assar
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Wes Peters <[EMAIL PROTECTED]> writes:
> Assar Westerlund wrote:
> > Why can't a file system have more than 2^32 files?
>
> Because if it does you can't stat it! There's a great case of circular
> reasoning for you. ;^)
The other reasoning goes like
Wes Peters <[EMAIL PROTECTED]> writes:
> Are hash collisions handled reasonably?
No, they're not handled at all. :-) Doing that would require:
1. remembering all the nodes that we have seen and the hash values
given to them
2. having some backup-hash to use for the node that collides and the
Wes Peters <[EMAIL PROTECTED]> writes:
> "Daniel C. Sobral" wrote:
> >
> > Just to expand a little bit more, some distributed filesystems *do
> > not* have a unique identifier like the inode.
>
> So then the FreeBSD client software should create one? Do they just assign
> a random number as the
Garance A Drosihn <[EMAIL PROTECTED]> writes:
> At 12:37 PM -0700 11/20/99, Wes Peters wrote:
> >It's not broken in this case. 2^16 (st_dev) is certainly enough to uniquely
> >indentify all mounted filesystems, and 2^32 is (by definition) enough to
> >uniquely indentify each of the files on a fil
Ben Rosengart <[EMAIL PROTECTED]> writes:
> On 12 Nov 1999, Assar Westerlund wrote:
>
> > Other than that, I think the
> > `make -j4' suggested for a single CPU in the handbook is a fairly good
> > approximation.
>
> On what basis?
Simple experiment
Ben Rosengart <[EMAIL PROTECTED]> writes:
> D'oh -- I *meant* to add "besides trying different values and measuring"
> -- if I had that much time on my hands, I wouldn't be worrying about how
> long a make world takes. :-)
I think trying to come up with a formula for calculating the optimal
valu
Ben Rosengart <[EMAIL PROTECTED]> writes:
> Does anyone know of a method for determining the optimal number of
> concurrent jobs with which to make world (or anything else for that
> matter), given the amount of RAM, speed of processor, version of
> FreeBSD, speed and layout of disk(s), etc.?
Try
Nate Williams <[EMAIL PROTECTED]> writes:
> How about the reverse, where you link in PIC compiled libraries into
> static (.a) libraries? Does this work?
Sure. Look at how lib${LIB}_pic.a is done i . PIC-code
is less efficient than non-PIC code.
/assar
To Unsubscribe: send mail to [EMAIL PR
Why trying to debug some locking code of my own I enabled
SIMPLELOCK_DEBUG, only to find out that I was getting lots of
`simple_unlock: lock not held' in lockmgr -> acquire -> apause.
Looking closer at `apause' it seems rather clear that it can cause
this. I proposed simple change is below.
Com
Charles Randall <[EMAIL PROTECTED]> writes:
> Under what conditions does bind(2) set errno to EAGAIN?
Either all ports being used up or malloc fails in the kernel.
/assar
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Greg Lehey <[EMAIL PROTECTED]> writes:
> The nice thing about kadb is that it has a usable macro languge.
Compared to ddb, yes. Compared to gdb, no.
/assar
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Krzysztof Krawczyk writes:
> Could someone say me, why the maximum packetsize in ping command is 8184
> (ping -s 8184)? If I want to do a bigger packetsize than this i got
> message like this:
Look at the sysctl variable `net.inet.raw.maxdgram'.
/assar
To Unsubscribe: send mail to majord...@fr
Krzysztof Krawczyk <[EMAIL PROTECTED]> writes:
> Could someone say me, why the maximum packetsize in ping command is 8184
> (ping -s 8184)? If I want to do a bigger packetsize than this i got
> message like this:
Look at the sysctl variable `net.inet.raw.maxdgram'.
/assar
To Unsubscribe: send
Zhihui Zhang writes:
> Your response suggests that I can not achieve the same result simply by
> using (I am using gdb 4.18):
>
> (gdb)set follow-fork-mode child
As far as I can tell, `set follow-fork-mode' only works on HP-UX.
/assar
To Unsubscribe: send mail to majord...@freebsd.org
with "u
Zhihui Zhang <[EMAIL PROTECTED]> writes:
> Your response suggests that I can not achieve the same result simply by
> using (I am using gdb 4.18):
>
> (gdb)set follow-fork-mode child
As far as I can tell, `set follow-fork-mode' only works on HP-UX.
/assar
To Unsubscribe: send mail to [EMAIL PR
Zhihui Zhang writes:
> Thanks for your response. I can not think of those points myself.
> However, on page 7 of the book "Panic! Unix system crash dump analysis",
> it says that a debugger named kadb in SunOS can load the real kernel
> during boot and treat the latter like a great, big, user pr
Zhihui Zhang <[EMAIL PROTECTED]> writes:
> Thanks for your response. I can not think of those points myself.
> However, on page 7 of the book "Panic! Unix system crash dump analysis",
> it says that a debugger named kadb in SunOS can load the real kernel
> during boot and treat the latter like a
John Polstra writes:
> 1. I have a pointer to a vnode and I want to get the corresponding
> dev_t and inode number. Is there a non-sleazy way to do that other
> than calling vn_stat?
I think you just want to call VOP_GETATTR(vp, vap, cred, proc) and
then look at vap->va_fsid and vap->va_fileid.
John Polstra <[EMAIL PROTECTED]> writes:
> 1. I have a pointer to a vnode and I want to get the corresponding
> dev_t and inode number. Is there a non-sleazy way to do that other
> than calling vn_stat?
I think you just want to call VOP_GETATTR(vp, vap, cred, proc) and
then look at vap->va_fsid
"Jung, Michael" writes:
> Ok How does one recreate /dev/lkm for 4.0-Current? It is no longer
> in /dev/MAKEDEV.
There's no LKM support in -current any longer.
/assar
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
"Steven Jurczyk" writes:
> How fast get real / absolute path of specified file. I try use
> readlink, but this slow (for path /home/web/docs/index.htm must be
> done 4 or more (if this path have symlinks) readlink's - for /home,
> /home/web, /home/web/docs and /home/web/docs/index.htm). Is any
> f
"Jung, Michael" <[EMAIL PROTECTED]> writes:
> Ok How does one recreate /dev/lkm for 4.0-Current? It is no longer
> in /dev/MAKEDEV.
There's no LKM support in -current any longer.
/assar
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the me
"Steven Jurczyk" <[EMAIL PROTECTED]> writes:
> How fast get real / absolute path of specified file. I try use
> readlink, but this slow (for path /home/web/docs/index.htm must be
> done 4 or more (if this path have symlinks) readlink's - for /home,
> /home/web, /home/web/docs and /home/web/docs/in
"Daniel C. Sobral" writes:
> Of foremost importance, though, check the license.
Are we still talking about irs? I don't find any particular strange
licenses in src/lib/irs in recent bind distributions:
/assar
/*
* Copyright (c) 1996,1999 by Internet Software Consortium.
*
* Permission to us
"Daniel C. Sobral" <[EMAIL PROTECTED]> writes:
> Of foremost importance, though, check the license.
Are we still talking about irs? I don't find any particular strange
licenses in src/lib/irs in recent bind distributions:
/assar
/*
* Copyright (c) 1996,1999 by Internet Software Consortium.
*
Marc Tardif writes:
> At first, I simply considered the "__P" as a syntax convention. But, then
> again, this kind of syntax has to be defined somewhere. I've looked all
> over the place but can't seem to put the finger on the source of this
> syntax.
It's in :
#if defined(__STDC__) || defined(_
Marc Tardif <[EMAIL PROTECTED]> writes:
> At first, I simply considered the "__P" as a syntax convention. But, then
> again, this kind of syntax has to be defined somewhere. I've looked all
> over the place but can't seem to put the finger on the source of this
> syntax.
It's in :
#if defined(__
Peter Jeremy writes:
> We need to be able to build an application that has no dynamically
> loaded code for recovery purposes (/stand and /sbin) as well as for
> security.
Isn't that the same problem as with PAM?
/assar
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freeb
"Brian F. Feldman" writes:
> As I read it, sockaddr is a transparent type (overloaded, as it were).
> So we would use something like:
> struct jail {
> ...
> struct sockaddr;
> char [SOCK_MAXADDRLEN - sizeof(struct sockaddr)];
> char [s
Soren Schmidt writes:
> > I started looking at the kernel modules and porting them, however, I
> > must confess that I don't fully understand exactly what the linux
> > kernel module does, which makes it somewhat harder to implement the
> > same functionality on FreeBSD :-)
>
> If you provide an
Peter Jeremy <[EMAIL PROTECTED]> writes:
> We need to be able to build an application that has no dynamically
> loaded code for recovery purposes (/stand and /sbin) as well as for
> security.
Isn't that the same problem as with PAM?
/assar
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "u
"Brian F. Feldman" <[EMAIL PROTECTED]> writes:
> As I read it, sockaddr is a transparent type (overloaded, as it were).
> So we would use something like:
> struct jail {
> ...
> struct sockaddr;
> char [SOCK_MAXADDRLEN - sizeof(struct sockaddr)];
>
Soren Schmidt <[EMAIL PROTECTED]> writes:
> > I started looking at the kernel modules and porting them, however, I
> > must confess that I don't fully understand exactly what the linux
> > kernel module does, which makes it somewhat harder to implement the
> > same functionality on FreeBSD :-)
>
Alfred Perlstein writes:
> I heard they have released the source to the kernel modules needed
> to run it.
>
> why not port them over? :)
I started looking at the kernel modules and porting them, however, I
must confess that I don't fully understand exactly what the linux
kernel module does, whi
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> I heard they have released the source to the kernel modules needed
> to run it.
>
> why not port them over? :)
I started looking at the kernel modules and porting them, however, I
must confess that I don't fully understand exactly what the linux
ker
"Brian F. Feldman" writes:
> On Tue, 3 Aug 1999, Mike Smith wrote:
> >
> > Actually, with interfaces like this you should generally pass a pointer
> > to the structure in userspace, and stick a version number constant in
> > the beginning of the structure. The size is often not enough of a
>
"Brian F. Feldman" <[EMAIL PROTECTED]> writes:
> On Tue, 3 Aug 1999, Mike Smith wrote:
> >
> > Actually, with interfaces like this you should generally pass a pointer
> > to the structure in userspace, and stick a version number constant in
> > the beginning of the structure. The size is often
Alfred Perlstein writes:
> the problem with nfsrv_fhtovp is that it is overkill for my application
> (it checks perms where i don't need it to, so i would have to fake
> a lot of stuff to look like i was authorized)
What's your application?
> so instead I gutted nfsrv_fhtovp a bit and came up wi
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> the problem with nfsrv_fhtovp is that it is overkill for my application
> (it checks perms where i don't need it to, so i would have to fake
> a lot of stuff to look like i was authorized)
What's your application?
> so instead I gutted nfsrv_fhtovp
Warner Losh writes:
> Or getservbyname (which is really what you'd want to change). I have
> patches to inetd that I've enclosed here. They are gorss, but the
> code itself doesn't lend itself to non-gross patches w/o some rework,
> which I was too lazy to do this morning.
Or you might as well
Warner Losh <[EMAIL PROTECTED]> writes:
> Or getservbyname (which is really what you'd want to change). I have
> patches to inetd that I've enclosed here. They are gorss, but the
> code itself doesn't lend itself to non-gross patches w/o some rework,
> which I was too lazy to do this morning.
O
Dag-Erling Smorgrav writes:
> > And besides, I really don't think this is a grep function but actually
> > is useful for programs that don't have any strategy for handling out
> > of memory errors and might as well die (with a descriptive error
> > message, of course). Let's call it emalloc and l
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> > And besides, I really don't think this is a grep function but actually
> > is useful for programs that don't have any strategy for handling out
> > of memory errors and might as well die (with a descriptive error
> > message, of course). Let's c
Dag-Erling Smorgrav writes:
> - if ((realpat = malloc(strlen(pattern) + sizeof("^(") +
> - sizeof(")$") + 1)) == NULL)
> - err(1, "malloc");
> + realpat = grep_malloc(strlen(pattern) + sizeof("^(")
> + + sizeof
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> - if ((realpat = malloc(strlen(pattern) + sizeof("^(") +
> - sizeof(")$") + 1)) == NULL)
> - err(1, "malloc");
> + realpat = grep_malloc(strlen(pattern) + sizeof("^(")
> +
83 matches
Mail list logo
