Re: Return value of malloc(0)
On Thu, 29 Jun 2006, Johannes Weiner wrote: JWOn Thu, Jun 29, 2006 at 06:09:37PM +0200, Matthias Andree wrote: JW JW The value returned from malloc(0) must not be dereferenced whatever it JW was. It was 0x800, which doesn't count as failure. JW JWBut this would be appropriate for catching the error: JW JWif ((foo = malloc(0)) == foo) JW /* make noise */ JW JWwouldn't it? Wouldn't it rather invoke undefined behaviour? harti ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
On Thu, 29 Jun 2006, Matthias Andree wrote: MAJohannes Weiner [EMAIL PROTECTED] writes: MA MA On Thu, Jun 29, 2006 at 06:09:37PM +0200, Matthias Andree wrote: MA MA The value returned from malloc(0) must not be dereferenced whatever it MA was. It was 0x800, which doesn't count as failure. MA MA But this would be appropriate for catching the error: MA MA if ((foo = malloc(0)) == foo) MA/* make noise */ MA MA wouldn't it? MA MANo, sir. Operator precedence: assign first, and then compare, thus the MAcomparison will always be true (else you'd be comparing to undefined MAvalues, which isn't any better). You might as well write: Operator precedence is just for parsing, not for evaluation. The compiler may well first evaluate the foo on the right side of the == (by fetching it) and then go an call malloc and assign foo. It is actually undefined behaviour, I think, so it may well make explode your near-by atom power plant. harti MA MA foo = malloc(0); MA /* make noise */ MA MAThere is no way to see a 0x800 return from malloc(0) as error. MA MA ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
pam_krb5 problems
Hi all, has anyone successfully configured pam_krb5? It seems that the ticket verification that is in the code does not work as intended: I have a host key in my keytab, but reading it for verification fails, because pam_krb5 constructs the principal name host/[EMAIL PROTECTED] while the keytab contains just [EMAIL PROTECTED] When I try to add the host/... principal to the keytab, kinit -k doesn't work anymore. Another problem is finding the realm for the host. I have to explicitely add the mapping for the host to the realm to krb5.conf. I have a _kerberos TXT record in DNS, but the library fails to DNS-search for _kerberos or _kerberos.kn.op.dlr.de, but searches for _kerberos.opkndn_beagle.. (note the '.' at the end) which seem just wrong. What do I wrong here? harti ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern.ngroups (non) setting ... new bounty ?
On Thu, 27 Sep 2007, Pietro Cerutti wrote: PCPawel Jakub Dawidek wrote: PC On Tue, Sep 25, 2007 at 09:51:06AM -0700, rsync.net wrote: PC It has been impossible to change kern.ngroups - at least for several years PC now. It was not fixed in either 5.x or 6.x : PC PC http://lists.freebsd.org/pipermail/freebsd-bugs/2007-January/022140.html PC PC It is seemingly a difficult problem: PC PC http://www.atm.tut.fi/list-archive/freebsd-stable/msg09969.html [1] PC PC However it should be solved - we can't be the only ones out there trying PC to add a UID to more than 16 groups... PC PC PC - PC PC PC The rsync.net code bounties have been fairly successful this year - two of PC the five projects have been completed, and the large vmware 6 on FreeBSD PC project is now underway. PC PC We'd like to add a new bounty for this kern.ngroups issue. We are posting PC to -hackers today to get some feedback on how long this will take and how PC much money might reasonably be expected to lure this work. PC PC PC --rsync.net Support PC PC PC PC [1] Is it indeed true that these programs are broken by not following PC NGROUPS_MAX from syslimits.h? PC PC I don't see how they can be broken. They may not see more than 16 PC groups, but they shouldn't blow up. The only possibility of bad usage I PC see is something like this: PC PCgid_t gids[NGROUPS_MAX]; PCint gidsetlen; PC PCgidsetlen = getgroups(0, NULL); PCgetgroups(gidsetlen, gids); PC PC But I guess the most common use is: PC PCgid_t gids[NGROUPS_MAX]; PCint gidsetlen; PC PCgidsetlen = getgroups(NGROUPS_MAX, gids); PC PC Binaries using the latter method should be just fine. PC BTW. The latter method is what all utilities from the base system use. PC PC PCAnyway, why should we worry about possible breakage software written PCwith a bad design? We should worry about all software in the base system. Especially if the implications are security related. BTW - the software is not necessary bad designed - it may just be old. There are things to think about: in several places the group list would be truncated: NFS, struct ucred, struct xucred, struct kinfo_proc, struct cmsgcred (this is just from a grep in include/sys). Truncating is ok as long as you use group membership only to give access to a ressource - the user will just not be able to access a ressource that in principle he should be able to access. Unfortunately someone in the past thought that making negative decisions based on group membership would be a nice thing (prominent example: NTFS). Here truncating the group list has the effect of giving access to resource the user should have no access to. I don't think the brain-dead concept of deny groups is used anywhere in the base system, but applications certainly could use it and in this case surprises are just waiting to pop up by ignoring the truncation problem. harti ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern.ngroups (non) setting ... new bounty ?
On Wed, 26 Sep 2007, rsync.net wrote: r r rOn Wed, 26 Sep 2007, Julian Elischer wrote: r r rsync.net wrote: r It has been impossible to change kern.ngroups - at least for several years r now. It was not fixed in either 5.x or 6.x : r r http://lists.freebsd.org/pipermail/freebsd-bugs/2007-January/022140.html r r It is seemingly a difficult problem: r r http://www.atm.tut.fi/list-archive/freebsd-stable/msg09969.html [1] r r However it should be solved - we can't be the only ones out there trying r to add a UID to more than 16 groups... r the big question is what do you do for NFS? remember something about r it only having a fixed storage for groups. r r r (snip) r r r [1] Is it indeed true that these programs are broken by not following r NGROUPS_MAX from syslimits.h? r r r Assuming the answer to the above footnote is yes, would it be reasonable r to fix the OS generally, but continue to hard code the limits in things r like NFS ? r r Are you saying that, unlike other items, NFS _does_ respect NGROUPS_MAX ? r r actually it doesn't r r see: r r nfs/rpcv2.h:#define RPCAUTH_UNIXGIDS 16 r r but what do we do if a user has 16? r r rWe have no idea. All we know is, we need some UIDs to be members of more rthan 16 groups, and that is currently impossible. r rWe are happy to lend financial support to a solution ... however it sounds rlike $500 and free rsync.net storage space isn't going to be sufficient ? r rIs it unexpected that someone has run into this limit ? I have :-) There is an easy solution: Bump NGROUPS_MAX and recompile everything. Be aware that in some cases the group list is truncated: NFS and socket credentials (there may be more). I've done this over a year ago on my desktop because I'm in 50 groups that come from an active directory. Making this changeable via sysctl involves more work (see for example struct kproc_info). harti ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make: evaluation of symbolic link with ../ fails
On Mon, 5 Nov 2007, Julian Stacey wrote: JSI found some unexpected behaviour within make on 6.2-RELEASE, JSNot sure if it's a bug, or proper behaviour. Comment please ? JS JSMake seems to be being too clever, evaluating where it JSthink the CWD (current working directory) is, whereas I think JSit should better let the external per line shell discover for itself. JSMake fails to realise that because of symbolic links, it is not JSacceptable to shorten JS cd /site/home/jhs/pics/.. ; rdist JSto JS cd /site/home/jhs ; rdist JS JSHow I discovered the behaviour: JS I keep my data split in 2: JS Some small enough to back up to a USB stick, eg: JS /usra/home/jhs/._/txt/ JS some bulky eg: JS /usra/jhs/xtra/pics JS using symbolic links eg JS /site/home - /usra/home JS ~/.HOME - /site/home/jhs/._ JS ~/txt - .HOME/txt JS ~/pics - .HOME/pics JS ~/._/pics - xtra/pics JS ~/._/xtra/pics - /usra/jhs/xtra/pics JS JS Some links are more complex than shown, for reasons JS beyond scope of this posting, but it's all been working fine JS for 8 years I've had patches to 2.2.8 onward JS kernels to increase the allowed traversal count for sym JS links etc JS http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/sys/sys/param.h.REL=ALL.diff JS JSIt's been fine while I manually ran: JS cd ; rdist `hostname -s` JS cd ~/xtra/LN ; rdist xtra # LN - /usra/jhs/xtra JSThe make behaviour was noticed when I embeded those lines in a Makefile. JS JSHere's some to try yourself: JS# Warning cant use eg ~/pics/../Distfile JSbug1: JS -cd ~/txt/.. pwd JS @# /usr/home/jhs JS -cd ~/txt/.. /bin/pwd JS @# /usra/home/jhs JS -cd ~/txt cd .. /bin/pwd JS @# /usra/home/jhs JS -cd ~/._/txt/.. /bin/pwd JS @# /usra/home/jhs/._ JSbug2: JS cd ~/pics pwd JS @# /usr/home/jhs/pics JS cd ~/pics/.. pwd JS @# /usr/home/jhs JS cd ~/pics /bin/pwd JS @# /usra/jhs/xtra/pics JS cd ~/pics/.. /bin/pwd JS @# /usra/home/jhs JS JSSee from results marked @#, make is evaluating eg JS cd ~/txt/.. ; rdist JSas if it's equivalent to JS cd ~; rdist JS it's Not equivalent, JSif I do eg: JS cd ~/pics/.. ; rdist JSrdist6 runs using the Distfile in my ~/Distfile, rather than different JS/usra/jhs/xtra/Distfile. JS JSI can cludge round this make behaviour, eg by in Makefile avoiding the ../ in JS cd ~/xtra/pics/.. rdist -f /usra/jhs/xtra/Distfile pics JSbut seems make is trying to be too clever, failing, make would be better JSif it did less. JS JS(BTW, to avoid distracting answers: I know make invokes a seperate JSshell per line, that's not the issue, also not the issue is /usr/obj/ JSor which external interactive shell I use). Are you sure that this is not a problem with /bin/sh? Make always execs a shell if it finds special symbols like ';' in the line. It does not interprete the cd. What shell are you using (I mean in which shell did you do the successful tests above)? Try something like: .SHELL: name=sh path=/path/to/your/shell in the Makefile (given that you're not using a c-shell). If it works then the problem is in /bin/sh. harti ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clustering FreeBSD
On Tue, 30 Jan 2001, Peter Wemm wrote: PWMark Huizer wrote: PW | PW | Doh! I mean 9.8 m/s/s, of course. PW PW That's acceleration not velocity :-) PW PW The terminal velocity of a PC case is probably a lot lower than the PW velocity of an outer edge of a 1 RPM drive. PW PW What am I doing wrong? Given a diameter of appr. 7cm, I'd come at appr PW 0.7Mach. Does that mean that within a few years my machine will go PW KABOOM when booting? PW PWI have a 15K rpm drive if you want to do a recalculation. I think that PWis 1.05Mach, depending on whether you rounded or not. ;-) Well, 7cm gives 21cm per rotation or 2.1km for 1 rotations. 1 Rotations Per Minute give around 130km per hour which is somewhere around 0.1MACH. So I expect not problems until the drives reach 5 rpm :-) harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Problems with new RPC
Hi,
I described the problem a couple of days on -current, but either I'm
doing something dumb or nobody is using ypbind -- I got no answer up to
now. So here is it again:
the recent update to RPC causes ypbind to break. The problem is, that
/usr/src/usr.sbin/ypbind/yp_ping.c mirrors some code from the RPC library,
including the internal structure used for the CLIENT structure. The
version in libc uses a struct sockaddr_storage (128 bytes) whereas yp_ping
has a struct sockaddr_in (something lesser). The libc version also
includes a member just at the end of the structure (struct pollfd) that
the ypbind version does not have.
Because the XDR buffers are allocate directly behind struct CLIENT, this
makes the pointers into the buffer wrong. This causes the ypbind child to
dump core, which in turn causes the parent to create a new child, which
dumps core, causing the parent to create a new child, which dumps core ...
A simple fix (rather a workaround is):
Index: yp_ping.c
===
RCS file: /usr/ncvs/src/usr.sbin/ypbind/yp_ping.c,v
retrieving revision 1.8
diff -u -r1.8 yp_ping.c
--- yp_ping.c 2001/03/19 12:50:12 1.8
+++ yp_ping.c 2001/03/20 13:46:24
@@ -93,6 +93,7 @@
#include rpcsvc/yp.h
#include sys/socket.h
#include sys/ioctl.h
+#include sys/poll.h
#include net/if.h
#include "yp_ping.h"
@@ -126,7 +127,7 @@
struct cu_data {
intcu_sock;
bool_t cu_closeit;
- struct sockaddr_in cu_raddr;
+ struct sockaddr_storage cu_raddr;
intcu_rlen;
struct timeval cu_wait;
struct timeval cu_total;
@@ -136,6 +137,7 @@
u_int cu_sendsz;
char *cu_outbuf;
u_int cu_recvsz;
+ struct pollfd cu_pollfd;
char cu_inbuf[1];
};
Another problem which started at the day the RPC stuff was committed are
error messages of the form
yp_match: clnt_call: RPC: Program unavailable
spit out from various programs, among them pine, tcpdump, tcptrace.
How can I fix this (or at least find out, what's the problem)?
harti
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Problems with new RPC
On Fri, 23 Mar 2001, Gordon Tetlow wrote: GTIf you haven't, please please please, send-pr(1) this so the right people GTget a look at this. Last thing we need is a broken ypbind (not that I use GTit). More down below. Ok, don't panic :-) ypbind seems to work no. The ypmatch problem stil l exists (see other mail). And, well..., I thought submitting a send-pr to code that was imported only three days ago would be an overkill... harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Question regarding the array of size 0.
On Thu, 29 Mar 2001, Alfred Perlstein wrote:
AP* Peter Seebach [EMAIL PROTECTED] [010329 23:49] wrote:
AP In message [EMAIL PROTECTED], Todd Whitesel writes:
AP Just put a 1-element array at the end of your header struct, and account for
AP it when you work out how much extra space to allocate. C memory layout rules
AP guarantee that this usage will have the desired effect.
AP
AP Nope, not portable. The implementation is allowed to bust you for
AP overstepping the bounds of the array. :)
AP
AP The only portable solution is the new feature in C99.
AP
APWhich new feature?
struct foo {
double bar;
int baz[];
};
I suppose. But neither gcc nor Sun-cc seem to support it :-(
# gcc -c x.c
x.c:3: field `baz' has incomplete type
# cc -c x.c
"x.c", line 3: null dimension: baz
cc: acomp failed for x.c
Well, that's even lesser portability.
struct foo {
double bar;
int baz[0];
};
works for both compilers.
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
()s missing in condvar.h
Hi, ()s are missing around the macro argument in cv_waitq_empty. The call if(!(cv_waitq_empty(sc-foo_cv))) ... will otherwise fail to compile. harti Index: condvar.h === RCS file: /usr/ncvs/src/sys/sys/condvar.h,v retrieving revision 1.2 diff -r1.2 condvar.h 66c66 #define cv_waitq_empty(cvp) (TAILQ_EMPTY(cvp-cv_waitq)) --- #define cv_waitq_empty(cvp) (TAILQ_EMPTY((cvp)-cv_waitq)) -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
PRs
Hello, could someone please close kern/24628. This has been fixed. And could please somebody commit the one-liner in kern/27906. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
if_tap and devfs
Hello, I recently moved to using devfs and now if_tap seems unusable. Although the module is loaded, it doesn't show up in /dev or as an interface. From a quick comparison with if_tun it seems that this is 'expected' behaviour although I'm not a specialist with devfs. Is this so? If yes, is there somebody working to make if_tap devfs-ready? Or I'm doing something wrong? harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_tap and devfs
On Mon, 6 Nov 2000, Maksim Yevmenkin wrote: Hi Maksim, is there somebody working to make if_tap devfs-ready? Or I'm doing something wrong? [SNIP] it seems to me that it did not get commited. i will look into it again today and re-send patch to the list. Great! It works. (Minus a spelling error: the parameter in tapclone() should spell 'namelen'). Would nice if it get's committed. thanks, harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Strange thing with serial console speed
Hi, I have two machines running -current. One of them is configured for serial console and connected to the second one. On the 2nd one I usually build world and the kernels for the two machines. The I install world and the kernels from /usr/obj of the 2nd machine (exported via nfs). In principal this works just fine Except that I decided yesterday to raise the serial console speed to 115200 by putting the appropriate line into /etc/make.conf. I though, that this definition wouldn't matter for the machine without serial console. So I was really surprised to see, that that machine didn't boot anymore today. What happens is, that it prints the BTX loader version line, the cursor jumps to the upper left corner of the screen and there it stays until i press ctrl-alt-del or hit reset. Rebuilding /usr/src/sys/boot without the speed definition in /etc/make.conf fixes the problem. So, how is the serial console speed tangled to the non-serial console boot??? Is this a bug or a feature? Regards, harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ATM broken in -current
Hi,
the ATM stuff in /sys/dev/h{e,f}a and /sys/netatm seems to be seriously
broken in current. A simple 'atm show config' command leads to a kernel
panic. I have tracked down the problem (and had to learn, that bzero is a
function pointer rather than a function on i386).
I cannot track, how the problem was introduced, but it appears to be
somehow connected to phk's header file reorganisation in the ATM code in
october. Many of the files miss a sys/systm.h include and give a missing
prototyp warning for functions like splnet, printf, log, bzero...
This appears to be deadly for bzero(), because this is a function pointer
now. (I always had the fealing, that the ANSI-C syntax for calling
functions through pointers is bad ( fooptr() instead of (*fooptr)()).
Now I know why :-( ) Adding a #include sys/systm.h to the following
files seem to fix the problem:
dev/hea/eni_intr.c
dev/hea/eni_vcm.c
netatm/atm_if.c
netatm/atm_signal.c
netatm/atm_socket.c
netatm/atm_usrreq.c
netatm/ipatm/ipatm_event.c
netatm/ipatm/ipatm_if.c
netatm/ipatm/ipatm_load.c
netatm/ipatm/ipatm_output.c
netatm/ipatm/ipatm_vcm.c
netatm/spans/spans_cls.c
netatm/spans/spans_subr.c
netatm/uni/sscf_uni.c
netatm/uni/sscf_uni_lower.c
netatm/uni/sscf_uni_upper.c
netatm/uni/sscop.c
netatm/uni/sscop_lower.c
netatm/uni/sscop_subr.c
netatm/uni/sscop_upper.c
netatm/uni/uni_load.c
netatm/uni/uniarp_input.c
netatm/uni/uniarp_output.c
netatm/uni/uniarp_vcm.c
netatm/uni/unisig_encode.c
netatm/uni/unisig_mbuf.c
netatm/uni/unisig_msg.c
netatm/uni/unisig_print.c
netatm/uni/unisig_proto.c
netatm/uni/unisig_sigmgr_state.c
Regards,
harti
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
'naive' programs on ng_socket's
Hi, I try to use the feature described in the ng_socket man page - writing to a ng_socket node that has excatly one hook attached. This appears not to work. I use NgMkSockNode(NULL, cs, ds) to create my node, then I NGM_CONNECT it to another node. If I now write to the data socket, I get a EDESTADDRREQ. When I do a connect(), I get a EISCONN. Well, after looking into the code, it appears, that I should not call connect(). Ok. But in the first case, it appears, that the generic socket code in uipc_socket.c, sosend() is the victim. The ng_socket code never declares the socket as connected I guess the SS_ISCONNECTED should be set somewhere in ng_data_connect or soisconnected() should be called... harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
handbook submissions
Hi, what is the correct address to send handbook submissions (in text form, I'm not an SGML guru) to, so that they get picked up? I've send a submission several months ago to one of our committers, but he seems to be more involved with DF-BSD nowadays. harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
make installworld for non-root user
Hi all, is there an easy way for a non-root user to test the installworld target? I came up with make SHAREOWN=harti SHAREGRP=harti LIBOWN=harti LIBGRP=harti \ NOFSCHG=yes INFOMODE=644 INFOOWN=harti INFOGRP=harti MANOWN=harti \ MANGRP=harti BINOWN=harti BINGRP=harti DESTDIR=/t/scratch/harti/root/ \ installworld but that one breaks in libexec/pt_chown (which has a hard-coded BINOWN=root). Perhaps I can't see the obvious solution? harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make installworld for non-root user
On Wed, 7 Jul 2004, Ruslan Ermilov wrote: REOn Wed, Jul 07, 2004 at 09:57:52AM +0200, Harti Brandt wrote: RE RE Hi all, RE RE is there an easy way for a non-root user to test the installworld target? RE I came up with RE RE make SHAREOWN=harti SHAREGRP=harti LIBOWN=harti LIBGRP=harti \ RE NOFSCHG=yes INFOMODE=644 INFOOWN=harti INFOGRP=harti MANOWN=harti \ RE MANGRP=harti BINOWN=harti BINGRP=harti DESTDIR=/t/scratch/harti/root/ \ RE installworld RE RE but that one breaks in libexec/pt_chown (which has a hard-coded RE BINOWN=root). RE RE Perhaps I can't see the obvious solution? RE REMany bits hardcode owners/groups/modes/flags, but it's still REpossible to install as non-root. In fact, buildworld already REdoes this for you -- it uses src/tools/install.sh as INSTALL REto do it (see the BMAKEENV setting in Makefile.inc1). So it seems that: make SHAREOWN=harti SHAREGRP=harti INSTALL=sh `pwd`/release/install.sh \ DESTDIR=/somewhere installworld almost works. Almost, because bsd.lib.mk contains SHLINSTALLFLAGS += -fschg That case is not handled in install.sh and should probably read SHLINSTALLFLAGS += -f schg Additionally I had to add -fschg) shift;; to install.sh, because it seems that the installworld target uses the currently installed mk files not those from src/share/mk. The SHAREOWN SHAREGRP is needed because share/zoneinfo/Makefile passes these directly to zic. This could probably be fixed by calling zic during buildworld and just install the compiled files during installworld. Thanks for your help, harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make installworld for non-root user
On Wed, 7 Jul 2004, Ruslan Ermilov wrote:
REOn Wed, Jul 07, 2004 at 11:17:00AM +0200, Harti Brandt wrote:
RE to install.sh, because it seems that the installworld target uses the
RE currently installed mk files not those from src/share/mk.
RE
RENot until you call installworld with make -fMakefile.inc1
RENormally, src/Makefile is used and it calls installworld with
RE-m${.CURDIR}/share/mk. You can verify with ``make -n installworld''.
So that was probably just a pilot error from me.
RE The SHAREOWN SHAREGRP is needed because share/zoneinfo/Makefile passes
RE these directly to zic. This could probably be fixed by calling zic
RE during buildworld and just install the compiled files during installworld.
RE
REYes, I've been thinking of doing this for some years now. I will see if
REI can fix it easily, now that I have a good reason for it. ;)
Would be nice.. I'm currently stuck to use panther to test my patches for sparc
(my sparcs are still in Berlin) and I want to make sure that I don't break
installworld at least.
Thanks,
harti
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Problems with tiocget/seta
On Wed, 25 Aug 2004 [EMAIL PROTECTED] wrote: Some background... For the past three years I have been developing a Forth compiler for Linux. The kernel to my compiler is written in 100% pure assembler using NASM. The object code produced is almost identical to what the Forth compiler itself would produce were it were used to compile its own sources (some day). I accomplish this via liberal use of NASM macros. All I/O etc is accomplished using Linux syscalls, no external libraries are referenced. Linux is my BIOS :) The problem... I consider Isforth to be a worthy project, worthy enough to be ported to other processors and other operating systems. The PPC port is being done by a friend of mine and is almost complete. The FreeBSD port has been nearly complete for about EIGHT months. I am currenty at a complete loss as to how to fix the problem (even though i think i know what it is!) :/ One of the things that my compiler has to do is switch stdin out of canoniacal mode and switch off echo. In Linux the ioctl is working - in fbsd its not. have you get a look to freebsd ioctl request codes? they differ from Linux and FreeBSD. Im almost posative that i am passing correct values to the syscall yet stdin is still buffered after the call and is still echoing. I would truely love to get this up and running in FBSD but am in dire need of help. Im told that if anyone can help me YOU guys can (blame samy for getting you into this :)... If you don't find a solution giving a look to tcsetattr(3) implementation for FreeBSD could be a good idea. Especially cfmakeraw(). harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: please help with: warning: initialization makes integer from pointer
On Fri, 8 Oct 2004, Mike Hunter wrote: MHOn Oct 08, Harti Brandt wrote: MH MH On Fri, 8 Oct 2004, Dan Nelson wrote: MH MH Memset is actually not portable if the structure contains pointers because MH it would initialize the pointers to 0 values not to 0 pointers. A 0 MH pointer not necessarily has a 0 value. A pointer can be portably be MH initialize to the 0-pointer only by assigning NULL (or 0) (or by assigning MH another pointer that is alreay initialized). MH MHSick! MH MHAre there actually systems out there that don't have all-zero NULL pointers? If you ask this question on comp.std.c I'm sure you'll get a number of positive answers, but be prepared to start a _long_ thread :-) harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: please help with: warning: initialization makes integer from pointer
On Fri, 8 Oct 2004, Dan Nelson wrote:
DNIn the last episode (Oct 07), Andreas Klemm said:
DN Dear FreeBSD hackers,
DN
DN could somebody please help Jonathan, the dspam owner, how to code
DN this best under FreeBSD ?
DN
DN Please see his question below:
DN
DN On Thu, Oct 07, 2004 at 01:16:17PM -0400, Jonathan A. Zdziarski wrote:
DN I'm a little concerned about these warnings:
DN
DN pgsql_drv.c:873: warning: initialization makes integer from pointer without a
cast
DN pgsql_drv.c:874: warning: initialization makes integer from pointer without a
cast
DN
DN This could cause some problems with dspam. Is there a freeBSDish way to
DN do this:
DN
DNs-p_getpwnam = (struct passwd) { NULL, NULL, 0, 0, NULL, NULL, NULL };
DNs-p_getpwuid = (struct passwd) { NULL, NULL, 0, 0, NULL, NULL, NULL };
DN
DN Perhaps memset(s-p_getpwnam, 0, sizeof(struct passwd)) ?
DN
DNYes, memset would be much more portable. I don't think there is any
DNstandard that says how many fields struct passwd has, or if they must
DNbe in any order. POSIX names only 5 required fields and no order.
DN
DNYou could use designated initialization, but that's a C99 feature, and
DNsince you're initializing everything to zero anyway, memset is still
DNbetter.
Memset is actually not portable if the structure contains pointers because
it would initialize the pointers to 0 values not to 0 pointers. A 0
pointer not necessarily has a 0 value. A pointer can be portably be
initialize to the 0-pointer only by assigning NULL (or 0) (or by assigning
another pointer that is alreay initialized).
If you don't want to use designated initialisation and need portability,
you must either explicitely assign all the members that are definied in
the standard or use:
static const struct passwd passwd_0;
...
s-p_getpwnam = passwd_0;
...
harti
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questionable feature in FreeBSD pmake
On Thu, 28 Oct 2004, Dan Strick wrote:
DSOn Thu, 28 Oct 2004 03:23:02 -0700, I wrote:
DS
DS I just spent a *very* frustrating hour trying to figure out why the
DS FreeBSD make program was invoking all commands to make things in a
DS subdirectory named obj. I eventually discovered this gem in the
DS make man page:
DS
DS In addition, make sets or knows about the following internal
DS variables or environment variables:
DS
DS ...
DS
DS .OBJDIRA path to the directory where the targets are built. At
DSstartup, make searches for an alternate directory to place
DStarget files. It will attempt to change into this special
DSdirectory and will search this directory for
DSfound in the current directory. The following directories
DSare tried in order:
DS
DS1. ${MAKEOBJDIRPREFIX}/`pwd`
DS2. ${MAKEOBJDIR}
DS3. obj.${MACHINE}
DS4. obj
DS5. /usr/obj/`pwd`
DS...
DS
DS
DSA little while later Peter Pentchev responded:
DS
DS Actually, this feature lies at the base of the FreeBSD base system build
DS infrastructure, and it is pretty much The Feature that allows us to
DS build from read-only and/or NFS-mounted sources shared among wide swarms
DS of machines :)
DS
DSand
DS
DS Oh, and let's not forget cross-platform builds, too.
DS
DS
DSIt is clear that a great deal of current FreeBSD OS makefile practice
DSdepends on the feature. The tragedy is that it was never necessary to
DSmake the feature unavoidable. Its invocation should have been dependent
DSon using a special environment variable or make command option or makefile
DScommand or makefile variable. Unfortunately, it seems that its invocation
DSdepends only on the presence of a subdirectory named obj in the directory
DSin which the make command is invoked and there is NO WAY to avoid it.
DSThere seems to be absolutely nothing that I can put in my makefile to
DSturn the feature off or to undo its effect.
I think this should be made conditional on the .POSIX target in the
makefile. This way we don't loose this feature for system build but make
our make more useable for outside packages. I have not yet looked into
this.
harti
DS
DSIt seems that I have no alternative but to rename my obj directory.
DSCan someone suggest an alternative? Note that it is not possible for me
DSto set an environment variable (i.e. MAKEOBJDIR) before running make or
DSto add an option to the make command line. Any fix must be contained
DSentirely within the makefile. Setting .OBJDIR or MAKEOBJDIR within the
DSmakefile does not work. Placing a cd .. or cd $(.CURDIR) in front of
DSevery set of makefile shell commands is unthinkable.
DS
DSDan Strick
DS[EMAIL PROTECTED]
DS
DS(now *immensely* frustrated)
DS___
DS[EMAIL PROTECTED] mailing list
DShttp://lists.freebsd.org/mailman/listinfo/freebsd-hackers
DSTo unsubscribe, send any mail to [EMAIL PROTECTED]
DS
DS
DS
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questionable feature in FreeBSD pmake
On Thu, 28 Oct 2004, Sean Farley wrote: SFOn Thu, 28 Oct 2004, Dan Strick wrote: SF SF On Thu, 28 Oct 2004 03:23:02 -0700, Dan Strick wrote: SF SF I just spent a *very* frustrating hour trying to figure out why the SF FreeBSD make program was invoking all commands to make things in a SF subdirectory named obj. SF SFI just noticed this is in the BUGS section of make: SF The determination of .OBJDIR is contorted to the point of SF absurdity. SF SF It seems that I have no alternative but to rename my obj directory. SF Can someone suggest an alternative? Note that it is not possible for SF me to set an environment variable (i.e. MAKEOBJDIR) before running SF make or to add an option to the make command line. Any fix must be SF contained entirely within the makefile. Setting .OBJDIR or MAKEOBJDIR SF within the makefile does not work. Placing a cd .. or cd SF $(.CURDIR) in front of every set of makefile shell commands is SF unthinkable. SF SFWhy are you unable to do anything with the command-line? Any of these SFwill solve your problem. SFBourne: SFMAKEOBJDIR=/no_obj_here make SF SFBourne or CSH: SFenv MAKEOBJDIR=/no_obj_here make SF SFHere is a Makefile that does not use obj/. The special targets can be SFplaced into a file to be included into all your Makefiles. It only SFsuffers from a failed build where it will not rename obj to tmpobj. SF SF--- SF.BEGIN: SF mv tmpobj obj || mkdir obj SF SF.INTERRUPT: SF mv obj tmpobj .INTERRUPT is dangerous at the moment, because it is not called always and it's sometimes called in the wrong place. I have a fix for this. harti SF SF.END: SF mv obj tmpobj SF SFall: SF touch testing SF SFclean: SF rm -f testing SF--- SF SFSean SF ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Devilator - performance monitoring for FreeBSD
On Wed, 2 Feb 2005, Robert Watson wrote: RW RWOn Wed, 2 Feb 2005, Borja Marcos wrote: RW RWI'm not sure about the correct values in the process description RW to get a picture as accurate as possible of the cpu usage of different RW processes. I've seen that top uses p_runtime (FreeBSD 5 and FreeBSD 4), RW but I'm not sure if the value would be really useful. RW RWThis is very cool. :-) How are you currently extracting the information? RWOne of the things I've wanted to do for a while is make sure all this sort RWof thing is exposed via snmpd so that the information can be gathered RWeasily across a large number of hosts (say, 10,000). That could be a nice JUH (junior userspace hacker's) task to add a module to bsnmp. harti ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Makefile .for and .if expansion
On Sat, 12 Feb 2005, Kris Kennaway wrote:
KKThe following small makefile doesn't behave as one would naively
KKexpect:
KK
KKMANLANG?=foo
KKall:
KK.for i in ${MANLANG}
KK.if empty(${i})
KK@echo foo ${i}
KK.endif
KK.endfor
KK
KKports-i386%make
KKfoo foo
KKfoo
KK
KKI think this is because the .if evaluation is happening too early, and
KKit's not being done after the .for loop is expanded and the i variable
KKis set.
KK
KKIn order to get this to work I seem to have to do the following:
KK
KKMANLANG?=foo
KK.for i in ${MANLANG}
KKj= ${i}
KK.if (${j} != \\)
KK.for l in ${j}
KKk+= ${l}
KK.endfor
KK.endif
KK.endfor
KKall:
KK@echo ${k}
KK
KKports-i386%make
KKfoo
KK
KKIf I remove the inner .for it breaks, and if I remove the j assignment
KKit breaks. Also if I try and remove the use of k and put an echo
KKinside the inner .for (with the all: preceding the whole loop) it
KKbreaks.
KK
KKThis is extremely nasty.
KK
KKAm I missing an easier way to do this?
As far as I can see you just discovered the limitation of make that is
documented under the BUGs section in the man page. This is the result of
the quit simple minded .for implementation (it's basically like expanding
a macro).
harti
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Devilator - performance monitoring for FreeBSD
On Sun, 13 Feb 2005, Willem Jan Withagen wrote: WJWHarti Brandt wrote: WJW On Wed, 2 Feb 2005, Robert Watson wrote: WJW WJW RW WJW RWOn Wed, 2 Feb 2005, Borja Marcos wrote: WJW RW WJW RW I'm not sure about the correct values in the process description WJW RW to get a picture as accurate as possible of the cpu usage of WJW different WJW RW processes. I've seen that top uses p_runtime (FreeBSD 5 and FreeBSD WJW 4), WJW RW but I'm not sure if the value would be really useful. RW WJW RWThis is very cool. :-) How are you currently extracting the WJW information? RWOne of the things I've wanted to do for a while is make WJW sure all this sort WJW RWof thing is exposed via snmpd so that the information can be gathered WJW RWeasily across a large number of hosts (say, 10,000). WJW WJW That could be a nice JUH (junior userspace hacker's) task to add a module WJW to bsnmp. WJW WJWnet-snmp is able to run arbitrary external code to obtain values to be WJWmonitored, and it seem to be able to use modules (haven't used them yet). I know. But on the other hand net-snmp is huge while bsnmp is in the base system. harti WJW WJWI've been using net-snmp/mrtg already for as long as I can remember to WJWmonitor load and diskspace. Processes and other things with MRTG are IMHO WJWsort of troublesome since sample period is 5 minutes. And most processes WJWthat outlive that timespan are kernel/daemon processes. WJW WJWWhat I like about Borja's stuff is that he is able to plot more that just 2 WJWparams in 1 graph. WJW WJW--WjW WJW WJW WJW ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bus_dmamem_alloc strangeness
On Thu, 17 Feb 2005, Gerald Heinig wrote:
GHHi hackers,
GH
GHI've come across weird behaviour in bus_dmamem_alloc() whilst trying to
GHallocate small memory blocks (less than PAGE_SIZE) which have to be
GHaligned to PAGE_SIZE.
GHMy segment size is 2048, my maximum number of segments is 1 (it MUST be
GHcontiguous), my max. total segment size is also 2048 and my alignment
GHconstraint is 4k (PAGE_SIZE). However, the DMA memory I'm getting from
GHbus_dmamem_alloc() is NOT aligned to 4k.
GH
GHThe relevant code in sys/i386/i386/busdma_machdep.c is:
GH
GH=
GH
GH if ((dmat-maxsize = PAGE_SIZE)
GH dmat-lowaddr = ptoa((vm_paddr_t)Maxmem)) {
GH *vaddr = malloc(dmat-maxsize, M_DEVBUF, mflags);
GH } else {
GH /*
GH * XXX Use Contigmalloc until it is merged into this facility
GH * and handles multi-seg allocations. Nobody is doing
GH * multi-seg allocations yet though.
GH * XXX Certain AGP hardware does.
GH */
GH *vaddr = contigmalloc(dmat-maxsize, M_DEVBUF, mflags,
GH 0ul, dmat-lowaddr, dmat-alignment? dmat-alignment :
GH1ul,
GH dmat-boundary);
GH }
GH==
GH
GHMy lowaddr is BUS_SPACE_MAXADDR and I'm allocating 2k blocks which have to be
GH4k-aligned, which would imply the first if branch.
GH
GHSurely the code should adhere to the alignment restrictions and not simply
GHallocate memory without checking, or am I missing something here?
I discovered this problem when I wrote my ATM drivers years ago. My
workaround is to make sure that size = alignment for all memory blocks by
just allocating larger blocks. This seems just to work up to now.
harti
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Really simple patch...
Could please somebody make this little, trivial and obviuos patch, I requested it a while ago, or should I make a PR for it?? Hi, ()s are missing around the macro argument in cv_waitq_empty. The call if(!(cv_waitq_empty(sc-foo_cv))) ... will otherwise fail to compile. harti Index: condvar.h === RCS file: /usr/ncvs/src/sys/sys/condvar.h,v retrieving revision 1.2 diff -r1.2 condvar.h 66c66 #define cv_waitq_empty(cvp) (TAILQ_EMPTY(cvp-cv_waitq)) --- #define cv_waitq_empty(cvp) (TAILQ_EMPTY((cvp)-cv_waitq)) -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Format checking for sbuf_printf...
hello, given that the various printf's in systm.h are format-checked, it probably makes sense to add this to sbuf_printf also. Could somebody please commit this? harti Index: sbuf.h === RCS file: /usr/ncvs/src/sys/sys/sbuf.h,v retrieving revision 1.6 diff -c -r1.6 sbuf.h *** sbuf.h 2001/07/03 21:46:42 1.6 --- sbuf.h 2001/07/17 12:05:28 *** *** 58,64 intsbuf_bcpy(struct sbuf *s, const char *str, size_t len); intsbuf_cat(struct sbuf *s, const char *str); intsbuf_cpy(struct sbuf *s, const char *str); ! intsbuf_printf(struct sbuf *s, const char *fmt, ...); intsbuf_putc(struct sbuf *s, int c); intsbuf_overflowed(struct sbuf *s); void sbuf_finish(struct sbuf *s); --- 58,64 intsbuf_bcpy(struct sbuf *s, const char *str, size_t len); intsbuf_cat(struct sbuf *s, const char *str); intsbuf_cpy(struct sbuf *s, const char *str); ! intsbuf_printf(struct sbuf *s, const char *fmt, ...) __printflike(2, 3); intsbuf_putc(struct sbuf *s, int c); intsbuf_overflowed(struct sbuf *s); void sbuf_finish(struct sbuf *s); -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
ypbind broken...
Hi,
The last commit to ypbind (1.34) breaks parsing of the -S option.
The following patch should fix this.
harti
Index: ypbind.c
===
RCS file: /usr/ncvs/src/usr.sbin/ypbind/ypbind.c,v
retrieving revision 1.34
diff -c -r1.34 ypbind.c
*** ypbind.c2001/07/13 14:10:09 1.34
--- ypbind.c2001/07/19 11:06:07
***
*** 415,423
ypsetmode = YPSET_LOCAL;
else if (strcmp(-s, argv[i]) == 0)
ypsecuremode++;
! else if (strcmp(-S, argv[i]) == 0 argc i)
yp_restricted_mode(argv[i+1]);
! else if (strcmp(-m, argv[i]) == 0)
yp_manycast++;
else
errx(1, unknown option: %s, argv[i]);
--- 415,424
ypsetmode = YPSET_LOCAL;
else if (strcmp(-s, argv[i]) == 0)
ypsecuremode++;
! else if (strcmp(-S, argv[i]) == 0 argc i) {
yp_restricted_mode(argv[i+1]);
! i++;
! } else if (strcmp(-m, argv[i]) == 0)
yp_manycast++;
else
errx(1, unknown option: %s, argv[i]);
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: the =+ operator
On Fri, 10 Aug 2001, Rob wrote: RMy first post on hackers, so please don't flame me too bad :) I think Rthat only an old hacker can give me the answer :) R RI've searched far and wide on search engines to find out what the =+ Roperator does, to no avail. I'm porting some old code and found it. I Rmade a test program and compiled it with gcc, and all it appears to do Ris the same as regular assignment. But I'm wondering if in some day Rlong ago, it mean't something else? Thanks, Rob. Originally the operators like += and -= where written as =+ =-. This worked at least 'til the UNIX v7 compiler. With v6 or v7 the operators were changed to get rid of the problem what 'v=-7' means. To assign -7 to v you had to write 'v= -7'. So you must have _really_ old code (much of the v7 code was still written using the old operators). harti PS: the v7 compiler also had the undocumented operators \/ and /\ for min and max. harti. PPS: if the code is not so old, it may be possible that v=+7 actually means v= +7. Note, however, that KR has no unary +. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
On Fri, 24 Aug 2001, Eugene L. Vorokov wrote: ELV It's kinda late in the process to be complaining about this, but I just noticed this myself... ELV ELVWhy not just symlink csh to tcsh then ? ELV ELVvel@bugz:/sys/modules/paudit # ls -l /bin/*csh ELV-r-xr-xr-x 2 root wheel 740996 Aug 23 23:19 /bin/csh ELV-r-xr-xr-x 2 root wheel 740996 Aug 23 23:19 /bin/tcsh ^ ELV ELVIs this really reasonable ? What's wrong with hard links? # ls -l /bin/csh /bin/tcsh 16112 -r-xr-xr-x 2 root wheel 740880 Aug 10 14:35 csh 16112 -r-xr-xr-x 2 root wheel 740880 Aug 10 14:35 tcsh harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sysctls for hardware monitoring?
On Thu, 22 Nov 2001, Mike Meyer wrote: MMIn looking over the various options for monitoring the health of the MMhardware, I notice that it's pretty much a mess. All the software in MMquestion runs privileged and grovels through memory in some way. MM MMLinux uses a device driver that's a directory full of files holding MMsensor information. That doesn't seem to be the right direction for MMFBSD, though. An option that enabled a set of sysctls to collect the MMinformation seemed to be more approrpiate. MM MMComments? Suggestions? Brickbats? What's bad about using files? Just to be different? Isn't it easier to select, poll, kqueue, what ever on files than on sysctls? harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sysctls for hardware monitoring?
On Thu, 22 Nov 2001, Mike Meyer wrote: MMHarti Brandt [EMAIL PROTECTED] types: MM On Thu, 22 Nov 2001, Mike Meyer wrote: MM MMLinux uses a device driver that's a directory full of files holding MM MMsensor information. That doesn't seem to be the right direction for MM MMFBSD, though. An option that enabled a set of sysctls to collect the MM MMinformation seemed to be more approrpiate. MM MMComments? Suggestions? Brickbats? MM MM What's bad about using files? Just to be different? MM MMOther than having to deal with devfs in -current vs. -stable, nothing MMin particular. I'm just looking at the trend for doing things in MM-stable, which is to make read-only data from in the kernel available MMvia sysctls. For example, where Linux has /proc/net/dev and MM/proc/net/route, FreeBSD uses a sysctl to get the data. It's just annoying to need a special program to get at the values. For some parts of the MIB, like the interface MIB, even sysctl doesn't help - you need to write a program to look at these. I still think, its easier to read the fan speed by cat(1)-ing a file, than to fire up a special program for this. MMIsn't it easier to select, poll, kqueue, what ever on files than on sysctls? MM MMTrue, but none of the things you've named are useful for these MMhardware monitors. The only useful thing you can do is read the MMcurrent value. Not sure. You could have a file, that gives you events, like 'CPU to hot' or so. The the user space program wouldn't need to poll the values. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sysctls for hardware monitoring?
On Fri, 23 Nov 2001, Joerg Micheel wrote: JMOn Thu, Nov 22, 2001 at 12:08:16PM +0100, Harti Brandt wrote: JM It's just annoying to need a special program to get at the values. For JM some parts of the MIB, like the interface MIB, even sysctl doesn't help - JM you need to write a program to look at these. I still think, its easier to JM read the fan speed by cat(1)-ing a file, than to fire up a special JM program for this. JM JMIt really is user convenience against kernel bloat. I have a Linux JMdevice driver which tries to provice a /proc entry. The amount of JMprintf() style crap in there is really disgusting and it does not even JMreport half of what it should. I've long ago decided that for anything JMother than the trivial case a binary interface is the only way one can JMdeal with these situations. It is unfortunate for the few of us who JMlike Plan9, but how big a bitter pill are you prepared to swallow. Files don't have to be ascii, do they? There is hexdump and other stuff. And, reporting fan speed and temperature doesn't seem to be the case for a complicated binrary interface. SOAP Taking a Linux driver to argue against something doesn't really make sense. There is so many crap in the Linux kernel, that you can argue against anything: The crappy unix domain sockets don't work in Linux. Oh yeah, they are a bad idea anyway... /SOAP harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: BPF - Packet Reception
On Tue, 27 Nov 2001, Rajesh P Jain wrote: RPJThanks for all the replies. RPJ RPJIn linux, the packet reception can be done efficiently through the usage of ethernet sockets. RPJ RPJ In FreeBSD, one of the option is by using the BPF. But, as already commented, BPF is not a high performance device. RPJ RPJ So, Can anyone give an alternative way in FreeBSD (other than modifying the driver code), so that high packet-rate reception can be done by without dropping any of the packets ? man 4 ng_ether perhaps harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: tar and nodump flag
On Tue, 27 Nov 2001, Walter C. Pelissero wrote: WCPDavid O'Brien writes: WCP On Wed, Nov 21, 2001 at 02:18:42PM +, Walter C. Pelissero wrote: WCP How about adding the nodump flag processing in tar? WCP WCP This would be a *bad* idea. It would diverge our tar even more WCP than it already is -- which is so bad it isn't trival to update to WCP the latest version (ours is many years behind). WCP WCPDoes it mean we can't modify the BSD tar because it's already too WCPdifferent from the GNU tar, but at the same time we don't upgrade to WCPthe new GNU tar because it might require too much work adapting the WCPold mods to the new code? WCP WCPAm I wrong or this means the BSD tar code is frozen? WCP WCPDo you have a list of discrepancies (not a diff) between the current WCPBSD tar and the version of GNU tar it's based on? We might find out WCPthe new GNU tar doesn't need as much hacking as the old one needs. Perhaps it makes sense to switch to star instead? The last version is Posix conform, supports extended headers and ACLs. According to the star developer (Joerg Schilling) GNU tar is severly broken. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
cvsup.freebsd.org
What happend to this host? I cannot ping it more than 10 hours. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raw socket programming
On Sun, 6 Jul 2003, Alin-Adrian Anton wrote: AAIn file included from raw.c:7: AA/usr/include/netinet/ip.h:156: syntax error before `n_long' AA/usr/include/netinet/ip.h:159: syntax error before `n_long' You may want to include netinet/in_systm.h harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Race in kevent
Hi, I just had a crash while typing ^C to a program that has a kevent timer running. The crash was: callout_stop callout_reset filt_timerexpire softclock and callout_stop was accessing freed memory (0xdeadc0e2). After looking some time at the filt_timerdetach, callout_stop and softclock I think the following happened: Proc 1 Proc 2 -- -- filt_timerdetachsoftclock called call with Giant locked lock_spin(callout_lock) ... call callout_stop which hangs on lock_spin(callout_lock) sofclock finds the callout, removes it from its queue and clears PENDING unlock_spin(callout_lock) lock(Giant) blocks callout_stop finds the callout to be not pending and returns filt_timerdetach frees the callout ... unlock(Giant) softclock continues and calls the (stopped) callout KABOOM because the pointer used by filt_timerexpire is gone The problem seems to be that there is a small window where the callout is already taken off from the callout queue, but not yet called and where all locks are unlocked. callout_stop may just slip into this window and invalidate the callout softclock() is about to call as soon as it gets Giant (event with an non-MPSAFE callout the same problem exists although the window is much smaller). What to do? callout_stop already detects this situation and returns 0. As far as I understand the way to handle this is not to free the callout memory in filt_timerdetach() when callout_stop() returns 0, but let the callout be called. filt_timerexpire() should detect this situation and simply free the memory and return. Is this a possible solution? (Actually this requires some work, because the knote pointer that the filt_timerexpire() gets is probably also gone). harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Race in kevent
On Wed, 9 Jul 2003, John Baldwin wrote: JBOn 09-Jul-2003 Harti Brandt wrote: JB JB Hi, JB JB I just had a crash while typing ^C to a program that has a kevent timer JB running. The crash was: JB JB callout_stop JB callout_reset JB filt_timerexpire JB softclock JB JB and callout_stop was accessing freed memory (0xdeadc0e2). After looking JB some time at the filt_timerdetach, callout_stop and softclock I think the JB following happened: JBThis is becoming a common race unfortunately. :( See the hacks in JBmsleep() that use TDF_TIMEOUT in coooperationg with endtsleep() and JBthe recent commit to the realtimer callout code for ways to work around JBthis race. In both places the thread just sleeps until the timeout has fired (when I understand this correctly). While this is a possible workaround also for kevent() (which only holds Giant as far as I can see) this is by no means a solution for other callers. While looking through the tree I have found several issues with timeouts which probably should be resolved or they will hit us with SMP: - the CALLOUT_ACTIVE flag is not maintained correctly. softclock() fails to clear this flag after the timeout has fired. callout_stop() clears CALLOUT_ACTIVE if it finds the callout not PENDING. This is wrong if the callout is just about to be called (in this case it is !PENDING but ACTIVE). This makes callout_active() useless. - using callout_active() on a callout_handle. Callouts for callout_handles (timeout(9)) are allocated from a common pool. So you may just check the wrong callout if the callout has already fired and has been reallocated to another user. Handles allocated with timeout(9) can only be passed to untimeout(9) I think we should try to make the callout interface usable without races for the !MPSAFE case (see mail from Eric Jacobs). For the MPSAFE case the caller should be responsible for this. And we should probably better document the interface. Going to think about this... harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Race in kevent
On Wed, 9 Jul 2003, Eric Jacobs wrote: EJOn Wed, 9 Jul 2003 15:28:38 +0200 (CEST) EJ EJI didn't think of it in my original post, but perhaps we need a EJthissoftcheck pointer that works analogously to nextsoftcheck, EJexcept that instead of being advanced to the next entry in the queue, EJit is simply zeroed out when the entry is removed. softclock() could EJdetect this pointer being zeroed out just before it goes to call the EJcallout or timeout function and skip that invocation if that is the EJcase. EJ EJThis is definitely not a solution in the CALLOUT_MPSAFE case, however, EJbecause it would make no sense to try to verify this pointer in the EJunprotected area between the spin lock being dropped and the sleep EJlock being picked up. In the !CALLOUT_MPSAFE case, we know what the EJsleep mutex would be -- it is always Giant -- and so we can test the EJpointer after that point. EJ EJI am still not certain I am thinking clearly about this. I think for the MPSAFE case we should just make the callout flags to be correct (look at CALLOUT_ACTIVE) so that a caller has a chance to find out the current state of the callout. Otherwise the user of an MPSAFE callout should avoid races. This means: clearing CALLOUT_ACTIVE in softclock() after the callout has returned and the lock has been re-aquired. Probably returning without doing anything from callout_stop() when it finds the callout to be non-pending but active. For the !MPSAFE case, however, we should do something. I think your idea would work. The only problem I can see are wrong uses of callouts allocated by timeout() (for an example see dev/ray/if_ray.c). These should be fixed in the callers of timeout(9). Could you craft a patch? I would try it. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Race in kevent
On Thu, 10 Jul 2003, John Baldwin wrote: JB JBOn 10-Jul-2003 Harti Brandt wrote: JB On Wed, 9 Jul 2003, John Baldwin wrote: JB JB JBOn 09-Jul-2003 Harti Brandt wrote: JB JB JB JB Hi, JB JB JB JB I just had a crash while typing ^C to a program that has a kevent timer JB JB running. The crash was: JB JB JB JB callout_stop JB JB callout_reset JB JB filt_timerexpire JB JB softclock JB JB JB JB and callout_stop was accessing freed memory (0xdeadc0e2). After looking JB JB some time at the filt_timerdetach, callout_stop and softclock I think the JB JB following happened: JB JB JBThis is becoming a common race unfortunately. :( See the hacks in JB JBmsleep() that use TDF_TIMEOUT in coooperationg with endtsleep() and JB JBthe recent commit to the realtimer callout code for ways to work around JB JBthis race. JB JB In both places the thread just sleeps until the timeout has fired (when I JB understand this correctly). While this is a possible workaround also for JB kevent() (which only holds Giant as far as I can see) this is by no means JB a solution for other callers. While looking through the tree I have found JB several issues with timeouts which probably should be resolved or they JB will hit us with SMP: JB JBYes, they sleep until the callout has finished executing. Note that the JBcallout has _already_ fired. The common case is that it is blocked on JBthe lock that the code trying to stop the callout is holding. Thus, you JBare going to have to have special case code in your callout handler JB_anyway_ to handle these edge cases, so there really isn't a super-duper JBeasy-clean solution. This is with MPSAFE callouts. !MPSAFE callouts will block before calling the handler when the try to acquire Giant. I'm assuming here, that the thread that calls callout_stop() must already have Giant (this is a valid assumption, isn't it?). In this case we can clear the cached copy (c_func) of the callout in callout_stop() and softclock will notice this when it has aquired Giant. We just need to make this cached copy global. For the MPSAFE case there is nothing we can do I suppose. JB - the CALLOUT_ACTIVE flag is not maintained correctly. softclock() fails JB to clear this flag after the timeout has fired. callout_stop() clears JB CALLOUT_ACTIVE if it finds the callout not PENDING. This is wrong if JB the callout is just about to be called (in this case it is !PENDING JB but ACTIVE). This makes callout_active() useless. JB JBThe problem is in the API. One of the design goals is that a callout can JBre-fire itself. Thus, softclock can't touch the callout once it has fired JBit. This design goal is the reason for much of the confusion. JB JB - using callout_active() on a callout_handle. Callouts for JB callout_handles (timeout(9)) are allocated from a common pool. So you may JB just check the wrong callout if the callout has already fired and has been JB reallocated to another user. Handles allocated with timeout(9) can only JB be passed to untimeout(9) JB JBThe idea is that timeout(9) and untimeout(9) are a deprecated interface and JBcode should be using the callout(9) API instead. Note that timeout(9)'s can JBnever be marked MPSAFE. JB JB I think we should try to make the callout interface usable without races JB for the !MPSAFE case (see mail from Eric Jacobs). For the MPSAFE case the JB caller should be responsible for this. And we should probably better JB document the interface. JB JB Going to think about this... JB JBWell, you need to consider the design goal above as it throws several JBwrenches into the works. One possibility is that we could ditch the JBdesign goal. Another possibility is that we could expand the callout JBAPI to allow for periodict callouts and not just one-shot callouts. That would probably be a good idea. Scheduling the new callout before calling the callout routine would be a good idea. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
uma_zalloc() not checking flags
Given that uma_zalloc() has the same flags as malloc(9) shouldn't it check these flags like malloc(9) does? I would think we could copy the #ifdef INVARIANTS section at the beginning of malloc(9) to uma_zalloc_arg(). I just found a large number of calls in the ATM code that have just M_ZERO or even 0 flags. Anything against this check? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Committing a driver to -stable
Hi all, as far as I know new stuff should be first committed to -current and, if it turns out stable enough, MFCed to -stable. I would like to commit a driver to -stable that will not be in -current. The driver is for ProSum's ProATM card. I have recently committed a full busdma driver to current (patm(4)), that I hesitate to backport to -stable because it requires ATM infrastructure that we don't have in stable. On the other hand there is a -stable driver for this card from ProSum (www.prosum.fr) that is reported to be very stable under -stable :-), that several people use and that I would like to commit. So, can I do this? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
SMP problem with uma_zalloc
Hi all, it seems there is a problem with the zone allocator in SMP systems. I have a zone, that has an upper limit on items that resolves to an upper limit of pages of 1. It turns out, that allocations from this zone get stuck from time to time. It seems to me, that the following happens: - on the first call to uma_zalloc a page is allocated and all the free items are put into the cache of the CPU. uz_free of the zone is 0 and uz_cachefree holds all the free items. - when the next call to uma_zalloc occurs on the same CPU, everything is fine. uma_zalloc just gets the next item from the cache. - when the call happens on another CPU, the code finds uz_free to be 0 and checks the page limit (uma_core.c:1492). It finds the limit already reached and puts the process to sleep (uma_zalloc was called with M_WAITOK). - the process may sleep there forever (depending on circumstances). If M_WAITOK is not set, the code will falsely return NULL while there are still free items (albeight in the cache of another CPU). I wonder whether this is intended behaviour. If yes, this should be definitely documented. uma_zone_set_max() seems to be documented only in the header file and it does not mention, that free items may not actually be allocatable because they happen to sit in another CPU's cache. If it is not intended (I would prefer this), I wonder how one can get the items out of another's CPU cache. I'm not too familiar with this code. I suppose this should be done somewhere around uma_core.c:1485? Regards, harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
rc.d review/hint needed
Hi all, I have tried to hack the harp(4) pseudo-driver into rc.d/atm*. While doing this I have found a bug in these scripts and decided to fix it and un-.sh atm2.sh and atm3.sh. The problem with harp(4) is that the real physical interfaces need to be brought up BEFORE atm1 via ifconfig, while the interfaces created by atm1 must be configured (with netif) AFTER atm1. Could please someone with enough rc.d knowledge look at the patch at: http://people.freebsd.org/~harti/patches/rc.d.atm.html Regards, harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: file size different from ls to du
On Tue, 29 Jul 2003, Joshua Oreman wrote: JOUsually programs will manage their own sparse files; it's something hard JOto do at the shell. When I need a file for TCP performance tests I usually do dd if=/dev/zero of=file bs=1k count=1 seek=9 harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
panic in uma_zdestroy
Hi,
with a kernel from yesterday I get a panic on an SMP system when I
destroy a zone immediately after creating it. It have a driver (with the
probe routine set to return ENXIO) and the following module event
function:
/*
* Module loaded/unloaded
*/
int
en_modevent(module_t mod __unused, int event, void *arg __unused)
{
switch (event) {
case MOD_LOAD:
en_vcc_zone = uma_zcreate(EN vccs, sizeof(struct en_vcc),
NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, 0);
if (en_vcc_zone == NULL)
return (ENOMEM);
break;
case MOD_UNLOAD:
uma_zdestroy(en_vcc_zone);
break;
}
return (0);
}
When I load the module and unload it I get a panic with the following trace:
db trace
uma_zfree_internal(c083a200,0,0,0,c627b3c4) at uma_zfree_internal+0xb0
cache_drain(c627b300,1,c030547c,245,c0369740) at cache_drain+0xe3
zone_drain_common(c627b300,1,c030547c,461,0) at zone_drain_common+0x62
zone_dtor(c627b300,f4,0,dad4fc40,c01b0255) at zone_dtor+0x55
uma_zfree_internal(c0369660,c627b300,0,0,dad4fc60) at uma_zfree_internal+0x35
uma_zdestroy(c627b300,dad4fc84,c01adce0,c6302c40,1) at uma_zdestroy+0x2a
en_modevent(c6302c40,1,0,c5ea2000,c632c700) at en_modevent+0x4b
driver_module_handler(c6302c40,1,c658a804,dad4fcc0,c0183f61) at
driver_module_handler+0x120
module_unload(c6302c40,c02f00d9,1f1,0,0) at module_unload+0x1e
linker_file_unload(c632c700,0,c02f00d9,31b,c632f250) at linker_file_unload+0x81
kldunload(c6046ab0,dad4fd10,c0309978,3ee,1) at kldunload+0x9b
syscall(2f,2f,2f,bfbffd03,bfbffc1c) at syscall+0x2b3
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (305, FreeBSD ELF32, kldunload), eip = 0x80485b3, esp = 0xbfbff76c, ebp =
0xbfbffbcc ---
db
The uma_zfree_internal call is the first one in cache_drain (the one
that frees uc_allocbucket). The seconds argument to uma_zfree_internal in the
trace above seems rather strange to me. What is the problem here?
harti
--
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tuning HZ for semi-realtime applications
On Sun, 3 Aug 2003, Sean Hamilton wrote: SHGreetings, SH SHI have an application which has some task it must execute at some interval SH(approximately 1000 times per second.) This application calls select(2) in a SHloop, and uses its timeout parameter to try to keep the timing consistent. SH SHAt the end of a cycle, it sends out a large amount of network traffic. SHDuring the select loop, it expects to receive replies to all this traffic. SH SHShould I set HZ to 1000 (the frequency of my application) or should I set it SHto a much higher value? The CPU is running at around 2 GHz, and I set it as SHhigh as 50,000 with no problems. However, the granularity of my timeout SHappears to be restricted to 1/1000th of a second. I run almost all of my systems at HZ=1. 5 will break TCP as soon as you try to connect to systems that are a moderate round trip time away. The problem seems to be that the round trip time calculation is done in ticks and that overflows the variables at larger hertzes. You must also keep in mind that even on an otherwise idle system some processes can take longer than the 100usec when HZ=1. A typical problem are the MII status updates of several cards like the xl(4). The time they require has drastically been reduced but they still need around 900usec. harti SH SHI would like to use poll(2) instead of select, but it appears to take its SHtimeout parameter in milliseconds, which aren't precise enough to keep my SHtiming reasonable, especially if I ever need to increase my frequency. SH SHAnother option would be calling poll/select with no timeout, in a loop. SHHowever, this seems like a waste of CPU time. SH SHAlso, as I am doing large amounts of network traffic, which NIC (preferably SHgigabit) should I be using, to cause the least interference with my timing? SH SHI do not require realtime performance. I am just looking to have this run as SHsmoothly as possible. SH SHsh SH SH___ SH[EMAIL PROTECTED] mailing list SHhttp://lists.freebsd.org/mailman/listinfo/freebsd-hackers SHTo unsubscribe, send any mail to [EMAIL PROTECTED] SH -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dynamic reads without locking.
On Wed, 8 Oct 2003, Pawel Jakub Dawidek wrote: PJDHello hackers... PJD PJDI'm wondering... PJDJeffrey Hsu was talking about this at BSDCon03. PJDThere is no need to lock data when we just made simple read, for example: PJD PJDmtx_lock(foo_mtx); PJDfoo = 5; PJDmtx_unlock(foo_mtx); PJDbut only: PJDbar = foo; PJD PJDIMHO this is quite dangerous. PJDLet's see: PJD PJDthread1 thread2 PJDmtx_lock(foo_mtx); PJDfoo = data_from_user; PJDbar = foo; PJDfoo = MASK; PJDmtx_unlock(foo_mtx); PJD PJDIn this case we have really dangerous race if data from user are PJDsafe only when we made 'and' operation on them. PJDOR of course we can just store wrong value in 'bar' and this could PJDbe case of different problems. PJD PJDSo I'm not sure now if I understand everything well. We can't just say PJD'We never split such writes. We always do: foo = (data_from_user MASK)', PJDbecause author of some 3rd party kernel module will be sure that when PJDhe locks writes to some variable this operation is safe and he could PJDsplit such writes and in kernel could be dynamic read without lock. PJD PJDDoes this make any sense? You need to lock when reading if you insist on consistent data. Even a simple read may be non-atomic (this should be the case for 64bit operations on all our platforms). So you need to do mtx_lock(foo_mtx); bar = foo; mtx_unlock(foo_mtx); if foo is a datatype that is not guaranteed to be red atomically. For 8-bit data you should be safe without the lock on any architecture. I'm not sure for 16 and 32 bit, but for 64-bit you need the look for all our architectures, I think. If you don't care about occasionally reading false data (for statistics or such stuff) you can go without the lock. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dynamic reads without locking.
On Wed, 8 Oct 2003, Pawel Jakub Dawidek wrote: PJDOn Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote: PJD+ You need to lock when reading if you insist on consistent data. Even a PJD+ simple read may be non-atomic (this should be the case for 64bit PJD+ operations on all our platforms). So you need to do PJD+ PJD+ mtx_lock(foo_mtx); PJD+ bar = foo; PJD+ mtx_unlock(foo_mtx); PJD+ PJD+ if foo is a datatype that is not guaranteed to be red atomically. For PJD+ 8-bit data you should be safe without the lock on any architecture. I'm PJD+ not sure for 16 and 32 bit, but for 64-bit you need the look for all PJD+ our architectures, I think. PJD PJDBut I'm not talking about non-atomic reads. What I'm want to show is that PJDeven atomic read (without lock) is dangerous in some cases. PJD PJD+ If you don't care about occasionally reading false data (for statistics or PJD+ such stuff) you can go without the lock. PJD PJDI'm afraid that many developers thinks that atomic reads are always safe PJDwithout locks (there are many such reads in sources). I hope I'm wrong. Well, I see your point. If the writer does a non-atomic write by doing: foo = data; foo = mask; then nothing helps. If he would do foo = data mask; on an atomic object things may work (well, one has to read the C-standard to find out wether the compiler is allowed to convert the 2nd form to the first one.). harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dynamic reads without locking.
On Wed, 8 Oct 2003, Bruce M Simpson wrote: BMSOn Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote: BMS You need to lock when reading if you insist on consistent data. Even a BMS simple read may be non-atomic (this should be the case for 64bit BMS operations on all our platforms). BMS BMSOr keep a generation count to detect pre-emption (the devstat code does BMSthis, amongst other things), and try again if you lost the race. BMS BMSOr insist on atomic reads, which must complete and must not be pre-empted BMSby definition (although the SMP case is/can be different!). That does not help if the writes are semantically not atomic: foo = data; foo = mask; harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dynamic reads without locking.
On Wed, 8 Oct 2003, Bernd Walter wrote: BWOn Wed, Oct 08, 2003 at 12:12:22PM +0200, Pawel Jakub Dawidek wrote: BW On Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote: BW + You need to lock when reading if you insist on consistent data. Even a BW + simple read may be non-atomic (this should be the case for 64bit BW + operations on all our platforms). So you need to do BW + BW + mtx_lock(foo_mtx); BW + bar = foo; BW + mtx_unlock(foo_mtx); BW + BW + if foo is a datatype that is not guaranteed to be red atomically. For BW + 8-bit data you should be safe without the lock on any architecture. I'm BW + not sure for 16 and 32 bit, but for 64-bit you need the look for all BW + our architectures, I think. BW BW But I'm not talking about non-atomic reads. What I'm want to show is that BW even atomic read (without lock) is dangerous in some cases. BW BW + If you don't care about occasionally reading false data (for statistics or BW + such stuff) you can go without the lock. BW BW I'm afraid that many developers thinks that atomic reads are always safe BW without locks (there are many such reads in sources). I hope I'm wrong. BW BWIt depends on the architecture and usage. BWbar = foo might be non-interruptable, but that doesn't say anything BWabout cache consistency. BWIf foo was written by another thread then you can have trouble with BWregister caching unless the variable is volatile. BWIf the other thread was/is running on another CPU then you might read BWan outdated value from cache. BWmtx_lock/mtx_unlock takes care about caching. BW BWHowever - if you read a value (e.g.) for statistic output - then it BWwon't hurt to get a cached value which is a few subseconds behind the BWreal value. BWThe only point to take care in this case is that the read is atomic and BWthat all bytes in the read value are consistent. BW BWThe above mtx_lock/read/mt_unlock case doesn't make sense, because it BWonly garanties an up to date value, but you cache it in a local BWvariable which again brings it out of date when used outside the lock. You might (for what ever reason) not care that the value gets out of date later on, but care that it is correct and consistent in itself. In this case, if foo is large (64-bit or a structure) the mtx_lock/read/mtx_unlock makes perfect sense because it guarantees that the value is not changed while you're copying it (non-atomically). harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dynamic reads without locking.
On Wed, 8 Oct 2003, Bernd Walter wrote: BWOn Wed, Oct 08, 2003 at 02:11:12PM +0200, Harti Brandt wrote: BW On Wed, 8 Oct 2003, Bernd Walter wrote: BW BW BWOn Wed, Oct 08, 2003 at 12:12:22PM +0200, Pawel Jakub Dawidek wrote: BW BW But I'm not talking about non-atomic reads. What I'm want to show is that BW BW even atomic read (without lock) is dangerous in some cases. BW BW BW BWThe above mtx_lock/read/mt_unlock case doesn't make sense, because it BW BWonly garanties an up to date value, but you cache it in a local BW BWvariable which again brings it out of date when used outside the lock. BW BW You might (for what ever reason) not care that the value gets out of date BW later on, but care that it is correct and consistent in itself. In this BW case, if foo is large (64-bit or a structure) the mtx_lock/read/mtx_unlock BW makes perfect sense because it guarantees that the value is not changed BW while you're copying it (non-atomically). BW BWWe agree here, but the topic was for atomic reads. BWIf you read a 64 bit value you have to be shure that 64 bit values can BWbe read atomicaly and if they are also written atomicaly then there is BWno reason to worry about the cosistency of the value itself. BWI'm not shure if 64 bit values are atomic on all platforms, but they BWare on some - at least on alpha. BWOn all our platforms reading and writing 8, 16 and 32 bit values should BWbe atomic if they are naturaly aligned - correct me if I'm wrong. BWWell if you write a 32 bit value with byte acces (e.g. with byte order BWmacros), then you are lost even with a atomic 32 bit read. Well, yes. The original question, however, did non-trivial processing of the value on the writer side: foo = data; foo = mask; Even if foo is guaranteed to be atomic on your architecture a non locking reader may slip in just between writing into foo and masking it thus getting a (semantically) inconsistent or incorrect value. Therefor whether you need to lock to read even an atomic datatype depends on the atomicity of all writers with regard to the semantics of the value. Suppose you have a variable that should only have values between 0 and 31. You may define a uint8_t foo; (guaranteeing that the data type itself is atomic). But if a writer sets foo as above and you read foo without locking, you might get a wrong value: mtx_lock(...) foo = 77; - bar = foo; /* bar is 77 */ foo = 0x1f; mtx_unlock(...) Even if you write foo = data 0x1f it may not help (one has to understand all that stuff about sequence points in the C-standard). So you can go without locking in the reader only if: - the datatype is atomic (depends on your architecture) - all writers ensure that they write only consistent values to the variable The 2nd point needs very careful thinking in every case. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dynamic reads without locking.
On Thu, 9 Oct 2003, Jeffrey Hsu wrote: JH I'm wondering... JH Jeffrey Hsu was talking about this at BSDCon03. JH There is no need to lock data when we just made simple read, for example: JH JH mtx_lock(foo_mtx); JH foo = 5; JH mtx_unlock(foo_mtx); JH but only: JH bar = foo; JH JH IMHO this is quite dangerous. JH Let's see: JH JH thread1 thread2 JH mtx_lock(foo_mtx); JH foo = data_from_user; JH bar = foo; JH foo = MASK; JH mtx_unlock(foo_mtx); JH JH In this case we have really dangerous race if data from user are JH safe only when we made 'and' operation on them. JH OR of course we can just store wrong value in 'bar' and this could JH be case of different problems. JH JHThis case (along with some other cases where locks of atomic reads JHare required) is covered in the paper as JH JH But, one case where locks would be required is if the field JH temporarily holds a value that no one else is supposed to see and JH the writer, operating with the lock held, will store a valid value JH before releasing his lock. In this case, both the writer and JH reader need to hold the lock before accessing this field. Yes. When I read the C standard foo = data mask; wouldn't also help, because there is no sequence point in this statement except at the ;. So the compiler is free to compile this as foo = data, foo = mask; unless foo is declared as volatile (in this case the write to foo is supposed to have a side effect so that the compiler cannot write twice to foo when only one write is specified). So I suppose that a lockless read is (in MI code) only allowed if the object is 32-bit and is written too with a simple assigment or is declared volatile. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dynamic reads without locking.
On Fri, 10 Oct 2003, Tim Kientzle wrote: TKHarti Brandt wrote: TK Yes. When I read the C standard TKfoo = data mask; TK wouldn't also help, because there is no sequence point in this statement TK except at the ;. TK TKBefore anyone takes this particular line of reasoning seriously, TKI feel compelled to point out that sequence points have nothing to TKdo with this. TK TKa) Sequence points are an as if requirement. The TKprogram must produce the same results as if it TKstrictly obeyed sequence points. It doesn't have TKto really operate that way. (And, in fact, well-optimized TKprograms running on modern processors rarely do.) And that means, that at the semicolon the value of foo should be as if the compiler really compiled the expression as written. This does not mean, that he has to and this does mean, that while executing this expression foo can have any value. TKb) Sequence points say NOTHING about how multiple TKthreads or processors interact. TK TKSorry, but the C standard doesn't help here. The TKC standard does not address multi-threading at all. But it addresses signal handling which suffers from the same problem of atomic access to variables. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iSCSI
On Fri, 7 Nov 2003, Danny Braniss wrote: DBhi all, DB is there any interest/progress with SCSI over IP? DBI am asking because our NetApp is supposed to support it, and the other DBapproach, FiberChannel/EMC seems 'slightly' expensive. DB DBthanks, DB danny DBPS: all our servers are running Freebsd 4.[8-9] with great success Did you look into Joerg Schillings SCSI library? As far as I know it allows transport of SCSI over whatever connection you have. It should be included in the cdrecord sources (don't know whether there is a standalone port). You may also contact [EMAIL PROTECTED] harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-hackers Digest, Vol 42, Issue 6
On Fri, 9 Jan 2004, Markus Brueffer wrote: MBOn Friday 09 January 2004 11:27, Robert Klein wrote: MB On Freitag, 9. Januar 2004 10:33, Josef El-Rayes wrote: MB Lukas Ertl [EMAIL PROTECTED] wrote: MB On Fri, 9 Jan 2004, Josef El-Rayes wrote: MBtar xvfj file.tar.bz2 MB MB tar xvjf MB MB i do not think that the order of the parameters MB have any influence on the result. MB MB No, but the filename has to be right after the f. The following MB commands work, and both have the same result: MB MB tar -jxvf file.tar.bz2 MB tar -jxf file.tar.bz2 -v MB MB but the following does not work as you expect: MB MB tar -jxfv file.tar.bz2 MB MB In this command tar(1) tries to extract the file v. MB MB Example error message: MB $ tar -jtfv xfce-4.0.1-src.tar.bz2 MB tar (child): v: Cannot open: No such file or directory MB tar (child): Error is not recoverable: exiting now MB tar: Child returned status 2 MB tar: xfce-4.0.1-src.tar.bz2: Not found in archive MB tar: Error exit delayed from previous errors MB $ MB MBRemove the - from the front of the options-list and it will work in your MBlast example. So Josefs statement was correct. MB MBWhat I'm asking me, is why the - makes a difference, though I haven't looked MBat the sources, yet. The manpage states, that the - is only optional, so MBtar -jxfv and tar jxvf should be equivalent, but obviously they are not. Old tar (v7) and Posix (well, SUSv2) have no dash before the key (the first argument to tar). They take option values from the next arguments in the order the options appear in the key string: tar xfbv file.tar 2 x - no arg f - take next arg (file.tar) b - take next arg (2) v - no arg. Using a dash is a gnu-ism and should be avoided in scripts. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __restrict__ vs __restrict ?
On Sat, 17 Jan 2004, David O'Brien wrote: DOOn Fri, Jan 16, 2004 at 08:03:05PM -0800, Tim Kientzle wrote: DO No, we should be using the __restrict as coded. But I wonder why DO we can't just use restrict... DO DO Because that would really mess up any user program that used DO 'restrict' as a variable or function name. I think the DO current approach is the best. DO DOSuch code isn't portable to C99, which is still a goal of ours. I like DORU's suggestion, because it is straight C[99] code and not an DOabstraction. I'll do a 'make world' test and see if we'd have trouble DOwith RU's form. What about third party code that reads cdefs.h and is pre-c99? It's perfectly ok to use restrict as a name there. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Odd ACL question
On Sat, 7 Feb 2004, Tim Kientzle wrote: TKIn tinkering with libarchive's support for ACLs, TKI've run across a head-scratcher: TK TKJoerg Schilling's star archives ACLs as follows: TK TKuser::rwx,group::r--,group:mail:rw-:6,mask::rw-,other::r-- TK TKNote the group:mail:rw-:6 entry that contains a fourth TKfield with the uid/gid number. FreeBSD's acl_from_text TKchokes on this, although Joerg asserts that posix1e TKpermits additional fields. TK TKQuestion: Should acl_from_text be altered to ignore TKadditional fields? TK TKWhat I can't quite figure out is whether or not this TKuid/gid field is really useful. It seems like it might TKbe useful when moving archives across systems, but TKI'm not entirely convinced that it's right to restore TKthe uid if the username doesn't exist. TK TKQuestion: Is this a useful extension? It definitely is. Joerg and I had several hours of talk on this issue. If you, for example, restore on a system that usually gets its passwd from YP or LDAP and you don't have it available at the moment you'll appreciate the possibility to restore from numerical user ids. I think some tar's use 'nobody' inb such cases. This may leave users with undeletable files in their directories (undeletable for the user). As far as I know there are options to star that let you select the exact behaviour in these cases. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Odd ACL question
On Sun, 8 Feb 2004, Tim Kientzle wrote: TKOn Sat, 7 Feb 2004, Tim Kientzle wrote: TKJoerg Schilling's star archives ACLs as follows: TK TKuser::rwx,group::r--,group:mail:rw-:6,mask::rw-,other::r-- TK TKNote the group:mail:rw-:6 entry that contains a fourth TKfield with the uid/gid number. ... TK TKQuestion: Is this a useful extension? TK TKHarti Brandt responded: TK It definitely is. Joerg and I had several hours of talk on this issue. TK If you, for example, restore on a system that usually gets its passwd from TK YP or LDAP and you don't have it available ... TK TKAh. That's the example I needed. Now to figure out how to implement TKsuch functionality; hacking the acl library functions may TKnot be the best approach, but I'm equally dismayed by the prospect TKof duplicating the acl library functions in my code. ;-( TK TK As far as I know there are options to star that let you select the exact TK behaviour in these cases. TK TKThis is one difference between 'star' and my work: 'star' offers TKa great deal of control over the archiving/dearchiving TKprocess; my work tries to remove the need for such control TKby using intelligent algorithms. For example, bsdtar/libarchive TKdoesn't require you to specify the compression when reading archives; TKit determines it automatically. TK TKIn this case, I'm considering: TK * If the username exists, use that. TK * If the username does not exist and the UID is not already in TK use, issue a warning and use the UID. TK * If the username exists and the UID conflicts with the local TK system, ??? TK TKThis last case is the tough one. My temptation: map it to TKan unused UID, issue a warning about the remap, and keep going. That may cause the problem I described. This may leave a file in a user directory that the user cannot delete without intervention of the root user, but its probably the simplest solution. What about non-existing groups? I remember talking with Joerg about this, but cannot remember the outcome of this. You may want to ask him. TKThere are certainly rare cases where manual control is TKneeded. That's why I'm pleased that 'star' is available TKin ports. ;-) Are you going to replace that horrible thing called GNU tar in the bases system? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Odd ACL question
On Mon, 9 Feb 2004, Dan Nelson wrote: DNIn the last episode (Feb 09), Harti Brandt said: DN On Sun, 8 Feb 2004, Tim Kientzle wrote: DN TKOn Sat, 7 Feb 2004, Tim Kientzle wrote: DN TKJoerg Schilling's star archives ACLs as follows: DN TK DN TKuser::rwx,group::r--,group:mail:rw-:6,mask::rw-,other::r-- DN TK DN TKNote the group:mail:rw-:6 entry that contains a fourth DN TKfield with the uid/gid number. ... DN TK DN TK * If the username exists and the UID conflicts with the local DN TK system, ??? DN TK DN TKThis last case is the tough one. My temptation: map it to DN TKan unused UID, issue a warning about the remap, and keep going. DN DN That may cause the problem I described. This may leave a file in a DN user directory that the user cannot delete without intervention of DN the root user, but its probably the simplest solution. What about DN non-existing groups? DN DNAny file that a user creates, that user can delete. If you're talking DNabout a root user extracting something into a user's directory, that's DNdifferent, but you have the same problem even without ACLs. Yes, the question was, what to do with a file whose UID does not exist on the system. And, yes, this is about the root user. If you restore a file server for a couple of hundereds or thousands of user you probably don't want to fix undeleteable (by the users) file handish. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Odd ACL question
On Mon, 9 Feb 2004, Tim Kientzle wrote: TKHarti Brandt wrote: TK On Sun, 8 Feb 2004, Tim Kientzle wrote: TK TK TKIn this case, I'm considering: TK TK * If the username exists, use that. TK TK * If the username does not exist and the UID is not already in TK TK use, issue a warning and use the UID. TK TK * If the username exists and the UID conflicts with the local TK TK system, ??? TK TK TK TKThis last case is the tough one. My temptation: map it to TK TKan unused UID, issue a warning about the remap, and keep going. TK TK That may cause the problem I described. This may leave a file in a user TK directory that the user cannot delete without intervention of the root TK user, but its probably the simplest solution. TK TKThis would only happen if you are restoring an archive onto TKa different system. If it's the same system, there should be TKno UID conflicts and thus no need to remap the UIDs. Theoretically yes, practically now. In our institute, for example, we make a backup every day (a incremental of course). People come and go and user names and ids are never reallocated, but get deleted after some time. So if you restore a backup that is say, half a year old, you may well have files that belong to no known user, even if restoring to the same system. I suppose that mapping them to a well known user (not necessarily 'nobody') and doing some clever 'find' afterwards would find these files. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
telnetd/sshd and Kerberos tickets (PAM)
Hi all,
I have enabled the pam_krb5 module in pam.d/{login,telnetd,sshd}. When
login in locally I get a Kerberos ticket as I would expect. When logging
in via ssh or telnet I don't get one. I have digged around in the sources
and it locks like telnetd never calls pam_setcred() which would do this
work. My PAM-foo is rather limited so my question is: shouldn't sshd and
telnetd call pam_setcred() somewhere?
harti
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: telnetd/sshd and Kerberos tickets (PAM)
On Fri, 21 Oct 2005, Stijn Hoop wrote:
SHOn Fri, Oct 21, 2005 at 04:08:14PM +0200, Harti Brandt wrote:
SH I have enabled the pam_krb5 module in pam.d/{login,telnetd,sshd}. When
SH login in locally I get a Kerberos ticket as I would expect. When logging
SH in via ssh or telnet I don't get one. I have digged around in the sources
SH and it locks like telnetd never calls pam_setcred() which would do this
SH work. My PAM-foo is rather limited so my question is: shouldn't sshd and
SH telnetd call pam_setcred() somewhere?
SH
SHWRT sshd I bugged des@ about this but did not receive an answer :( See
SHthe attached mail.
Hmm. I digged around a little bit and found something:
http://bugzilla.mindrot.org/show_bug.cgi?id=789
From a first glance it seems that this bug was introduced by fixing
another bug.
harti
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Increasing size of if_flags field in the ifnet structure [patch
On Fri, 16 Aug 2002, Maxim Sobolev wrote: MSBTW, I've just realised that we can easily avoid breaking application MSABI by using currently unused ifr_ifru.ifru_flags[2] (aka. ifr_prevflags) MSfor storing another 16 flags. What do people think? The ifr_prevflags may be used by snmp daemons to provide the necessary atomic rollback. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Increasing size of if_flags field in the ifnet structure [patch
On Fri, 16 Aug 2002, Maxim Sobolev wrote: MS MS On Fri, 16 Aug 2002, Maxim Sobolev wrote: MS MS MSBTW, I've just realised that we can easily avoid breaking application MS MSABI by using currently unused ifr_ifru.ifru_flags[2] (aka. ifr_prevflags) MS MSfor storing another 16 flags. What do people think? MS MS The ifr_prevflags may be used by snmp daemons to provide the necessary MS atomic rollback. MS MSCould you please verify? Nothing in the base system uses it. Initially, MSifr_prevflags was added with the following log message (rev.1.50): MS MS Since ifru_flags is a short, we can fit in a copy of the flags MS before they got changed. This can help eliminate much of the MS gymnastics drivers do in their ioctl routines to figure this out. MS MSbut no drivers are using it so far. I veryfied only net-snmp-current. It doesn't use it (I guess that variable is not SNMP-writeable in net-snmp). I use it however in the bsnmp daemon for NgATM. Its the only way to guarantee the atomicity required by SNMP. Removing something from the ABI which you cannot do otherwise from userspace is always a problem, because it may break 3rd party software (I mean not binary breakage, but functional breakage). Well, while thinking about it: With a user settable PROXY flag there is no way for an application to find out whether the flag was already set or not if the application sets it, excpect by inspecting the ifr_prevflags field. So two applications fiddling with this bit may entirly confuse each other. Count me as a vote for keeping the field and breaking binary compatibility instead of functionality. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Increasing size of if_flags field in the ifnet structure [patch
On Fri, 16 Aug 2002, Maxim Sobolev wrote: MS MS On Fri, 16 Aug 2002, Maxim Sobolev wrote: MS MS MS MS MS On Fri, 16 Aug 2002, Maxim Sobolev wrote: MS MS MS MS MSBTW, I've just realised that we can easily avoid breaking application MS MS MSABI by using currently unused ifr_ifru.ifru_flags[2] (aka. ifr_prevflags) MS MS MSfor storing another 16 flags. What do people think? MS MS MS MS The ifr_prevflags may be used by snmp daemons to provide the necessary MS MS atomic rollback. MS MS MS MSCould you please verify? Nothing in the base system uses it. Initially, MS MSifr_prevflags was added with the following log message (rev.1.50): MS MS MS MS Since ifru_flags is a short, we can fit in a copy of the flags MS MS before they got changed. This can help eliminate much of the MS MS gymnastics drivers do in their ioctl routines to figure this out. MS MS MS MSbut no drivers are using it so far. MS MS I veryfied only net-snmp-current. It doesn't use it (I guess that MS variable is not SNMP-writeable in net-snmp). I use it however in the MS bsnmp daemon for NgATM. Its the only way to guarantee the atomicity MS required by SNMP. MS MS Removing something from the ABI which you cannot do otherwise from MS userspace is always a problem, because it may break 3rd party software MS (I mean not binary breakage, but functional breakage). MS MS Well, while thinking about it: With a user settable PROXY flag there is no MS way for an application to find out whether the flag was already set or not MS if the application sets it, excpect by inspecting the ifr_prevflags field. MS So two applications fiddling with this bit may entirly confuse each other. MS Count me as a vote for keeping the field and breaking binary compatibility MS instead of functionality. MS MSHmm, I do not really see how this flag may help your application. To set or MSreset some flag from if_flags you have to read current values of those MSflags, so that you can use that value instead of ifr_prevflags. Of course MSit introduces some tiny race condition, but I do not see how presence of MSifr_prevflags can help you in this case. Moreover, possibility of such MSrace IMO is quite low, as interface flags are usually updated very rarely. Well, yes, you are right that I cannot prevent the race. MSInstead your bsnmp daemons should be using other ways to serialise write MSaccess to interface flags (e.g. lock file). This would require all programs that fiddle with interface flags to use that same lock file (including ifconfig). It seems rather silly to me to use a heavy weight lock file, to fiddle with a kernel flag. Ok, I take my vote back :-) kill ifr_prevflags harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
driver attach/detach functions
Hi,
while trying to get rid of 'could sleep with mutex' messages a question
occured to me: is there any global mechanism that ensures that no two
threads enter the interface attach/detach functions at the same time?
If there is, there should be a hint in driver(9) probably. If there isn't
what is the canonical way to implement an MP-safe attach function? Some
drivers use
foo_attach(...)
{
mtx_init(sc-mtx, ...
mtx_lock(sc-mtx);
...
but this really doesn't help.
Regards,
harti
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
kernel basic block profiling
Hi,
${subject} seems not to work on -current. First of all 'man kernbb' tells
me to compile at least one kernel file with '-a'. Well, gcc tells me that
it doesn't know anything about '-a'. After some grepping in the gcc
sources I came to the conclusion, that -fprofile-arcs is what it wants.
But even then 'kernbb' gives me nothing on the new kernel and gdb shows
bbhead to contain a 0. As far as I could figure out, the profile-arcs uses
a ctor section and I somehow doubt, that this works in the kernel case.
So, is ${subject} usable on current or is it just a stale feature?
Regards,
harti
--
harti brandt,
http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
printing of uint64_t in the kernel
Hi, while porting the NgATM stuff to sparc64 I could not answer the following question: What is the correct way to printf() an uint64_t in the kernel. For i386 I need %llu, for sparc64 I need %lu or gcc will give a warning. I see two variants: 1. include inttypes.h or machine/_inttypes.h and use the standard printf format strings. 2. cast always to uintmax_t and use %ju. The first possibilities seems wrong, because one should not include a non-system header, the second because given a (hypothetical) machine with 128-bit uintmax_t this would incure a useless overhead. So what? harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Are there any on-going projects on v4l porting?
On Wed, 12 Mar 2003, Yury Tarasievich wrote: YTAt http://freebsddvb.narod.ru, there exists an adequately up-to-date YTport of linux DVB drivers, seemingly supporting DVB adapters up to rev.1.5. YT YTRegarding porting of V4L. I may be utterly wrong, but isn't the whole YTV4L/V4L2/V4L2-whatever thing rather made ad hoc, not really designed? YTCould something reincarnating BeOS (or even OS/2) multimedia subsystem YTbe better? Yes, last time I had a look at V4L2 it was utterly broken with regard to ingeneering. Using a O_ flag to the open call to tell the system that you are going to use only ioctl()s and stuff like that... harti To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Are there any on-going projects on v4l porting?
On Wed, 12 Mar 2003, Dan Nelson wrote: DNIn the last episode (Mar 12), Yury Tarasievich said: DN At http://freebsddvb.narod.ru, there exists an adequately up-to-date DN port of linux DVB drivers, seemingly supporting DVB adapters up to DN rev.1.5. DN DN Regarding porting of V4L. I may be utterly wrong, but isn't the whole DN V4L/V4L2/V4L2-whatever thing rather made ad hoc, not really designed? DN Could something reincarnating BeOS (or even OS/2) multimedia DN subsystem be better? DN DNI like the idea of putting this into the Xfree86 drivers and using the DNXVideo extension to drive everything. that doesn't require kernel DNmods. It does mean that you need to start X up to capture video, DNthough. The problem with this is probably the number of context switches and copies or IPC you need to get a frame. With 25 fps this is a problem. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Build options for kernel modules
On Fri, 21 Mar 2003, The Anarcat wrote: TAOn Fri Mar 21, 2003 at 07:16:58PM +0300, Yar Tikhiy wrote: TA On Fri, Mar 21, 2003 at 05:39:07PM +0200, Nikolay Y. Orlyuk wrote: TA On Fri, Mar 21, 2003 at 06:32:17PM +0300, Yar Tikhiy wrote: TA Hi there, TA TA Excuse my stupid question, but I seem to have no time to do the TA investigation by myself right now so I'd be glad to receive a brief TA answer from someone who has the information. TA TA As far as I can see, kernel modules should be built along with the TA kernel for the only reason of keeping their mutual interfaces in TA sync, has a source file defining such an interface changed. Is TA there currently no way to go further and affect a kernel module's TA built-in features with kernel config file options, besides modifying TA makefiles in /sys/modules? TA I think this isn't so. I have been already tried to compile some modules TA without compiling kernel and this trye has successful result, but without TA change options. TA I think modules must be build with same or less imports and same or more export to be correct TA for loading. TA TA Yeah, it's all right to compile modules w/o the kernel, but that's TA not exactly what I was asking about. My question was whether option TA FOO lines from a kernel configuration file could influence modules. TA TAI'm pretty sure they do. A great example is IPFIREWALL_* options: if TAthey don't influence the module, I think we have a problem. ;) How should they? The Makefiles for modules usually create the option files that normally are create by config options themself and set the options to 1. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A few questions about a few includes
On Sun, 3 Mar 2002, Erik Trulsson wrote:
ETOn Sun, Mar 03, 2002 at 10:27:17AM -0700, Ian wrote:
ET
ET In sys/proc.h:
ET
ET /*
ET * pargs, used to hold a copy of the command line, if it had a sane
ET * length
ET */
ET struct pargs {
ET u_int ar_ref; /* Reference count */
ET u_int ar_length; /* Length */
ET u_char ar_args[0]; /* Arguments */
ET };
ET
ET This does indeed seem to make little or no sense. Could someone explain
ET this? Is ar_args supposed to be a pointer or what?
ET
ET This is a common technique for defining a structure which is some
ET descriptive information about an array of objects is followed by an
ET open-ended array of those objects. (In this case the objects are
ET characters.) The ar_args member of the structure gives a name to that
ET location in the structure without reserving any space (and thus when the
ET technique is used, there can only ever be one [0] member and it must be at
ET the end of the structure). You access the open-ended array of objects just
ET as you would any other array embedded within a structure, E.G.
ET instance-ar_args[n].
ET
ET Not all compilers support defining zero-length arrays like this. And that's
ET a pity; it's an incredibly useful technique, and the alternatives to it are
ET not nearly as elegant and generally involve ugly recasting of pointers.
ET
ETFor those compilers that don't support zero-length arrays one can still
ETuse the same trick but with a one-element array at the end of the
ETstruct. One just has to remember to that element into account when
ETallocating memory for the structure. Slightly uglier, but not much.
ET
ETIt might be worth mentioning that this trick is not actually allowed
ETaccording to the C standard and in principle invokes undefined
ETbehaviour. OTOH, AFAIK the trick does work on all existing compilers,
ETso while it is not standard-conforming it is quite portable.
My ISO-C draft copy allows in section 6.7.2.1 paragraph 2 the last member
of a structure to be an incomplete array type and paragraph 16 shows an
example. Was this removed from the final standard?
harti
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: A few questions about a few includes
On Mon, 4 Mar 2002, M. Warner Losh wrote:
MWLIn message: [EMAIL PROTECTED]
MWLErik Trulsson [EMAIL PROTECTED] writes:
MWL: I think it is still there (and my draft copy says the same thing).
MWL: I was thinking about the original C89 standard which does not allow it
MWL: (and does not allow incomplete array types in structs). Guess I should
MWL: have said which standard I was referring to.
MWL
MWLstruct foo {
MWL char array[0];
MWL};
MWL
MWLappears to be in C-99 but not C-89. If you have the draft, so far
MWLthe only thing I've noticed that is different between the draft
MWLand the final standard is that there's 10-15 more footnotes in the
MWLfinal standard than were in the final draft.
MWL
MWLWarner
This should be
struct foo {
char array[];
};
according to C-99, on which gcc2 barfs. Don't know, whether gcc3 can
handle this.
harti
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
On Tue, 5 Mar 2002, Eugene L. Vorokov wrote: ELVI have a small problem. I work for software development company and ELVwrite daemons and console tools for Unix. My boss wants everything ELVto be written in C++, because he thinks C++ is cool. I prefer C ELVfor such tasks, but I cannot really put good arguments of why and ELVwhere C++ can be worse than C. I know many of you prefer C too. ELVCan you please explain some disadvantages of C++ comparing to C ? ELVIs it slower, does it produce less effective code, why is it like ELVthat, etc ... or please direct me to some articles where this can ELVbe explained. ELV ELVI apologize for the offtopic whenever it happens, but this issue ELVreally pisses me off now. Well there are (at least) two reasons, why I wouldn't use C++ for the type of program I suppose you are writing: 1. The machine model used by C more or less maps directly into the machines used by most computers. By looking at a statement you can more or less guess what the compiler will do. In C++ this is not the case for (at least) two features: exceptions and virtual methods. Both of these features have an overhead, that cannot be estimated in advance. You can of course not use these features. 2. C++ turns out to be harder to read except it is extremly good written. This stems from several features of the language: a) operator overloading. Seeing a '+' doesn't mean that something is added. It may even actuall be a subtraction. It may be an assignment (a once popular GUI library used '+' to add dialog elements to the window on the left side of the '+'). b) function overloading. In C it is simple to lookup a function when you find it called in a program. In C++ you have first to lookup the argument types. If these are objects, you have also to find out the entire inheritance hierarchy. Then you have a quite complicated ruleset to find out, what function is really called. c) hidden function calls all over the places. You never know, whether a statement does something simple or call a lot of functions. 'a = b' can invoke dozens of constructors and other functions you are not aware of. Also there were rumours that C++ is less efficient because the resulting object code tends to consist of many small functions scattered all over the address space calling each other. This may badly hit cache performance. Well, the main problem with this type of question is that the choice of language depends on the problem you try to solve. For number crunching Fortran may still be the language of choice, for GUI programming surely it is C++ (or objc or java, you name it), for inetd it is probably C. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Swapping performance
On Thu, 7 Mar 2002, cjp wrote: You are probably misinformed, because FreeBSD also does overcommit of memory. If you look up the mail archives you will find long battles about the pros and cons of this. harti cThis is a comparison of how fast Linux can do something cSTUPID versus how fast a real OS can do something intelligently. Your ctest is giving you misleading, and dangerous numbers. Do not go waving them caround until you have actually looked at mallocs behavior on the different csystems. c cHere's why: c cLinux implements a brain dead memory allocation cscheme called memory overcommit. It will let you malloc cas much memory as you want whether it is available as RAM or not cand only bitch when you try to use the memory. Therefore, cLinux malloc is much faster than any reasonable system, since all it is doing is chanding out address space out of unallocated address space, cnot keeping track of how much memory there actually is. c cIn order to handle the kruft that occurs, there is the out of memory killer, coom_killer. cWhich merrily goes through the list of processes, killing off the low priority cprocesses cuntil enough memory is free to satisfy what was most recently used. It's the cloan shark crepayment program, with OOMKiller performing the function of the deliquency creminder. c cOn any of the BSD system, you actually get memory you can use, and all the coverhead cof assuring its existence at the time of allocation. Much more robust, less cprone to abuse. c cTry it, you'll like it. If you want the nuts and bolts of it, read the source. c c c- Original Message - cFrom: Dimitar Peikov [EMAIL PROTECTED] cTo: [EMAIL PROTECTED] cSent: Thursday, March 07, 2002 3:45 AM cSubject: Swapping performance c c c I start some performance tests on -stable and on SuSE 7.1 / 2.4.17. I c don't comment about 'bzero' performance, but when RAM is over, Linux c is much faster. I have no idea what is the algorithm of swapping but it seems cthat the granularity of swapping pieces is the key or the importance of swapping cmemory blocks of certain task. Ooo I forgot to say that the both machines have cthe same hardware, IBM 300PL, 256 RAM and no other tasks running. I had to run cthese tests to choose the fastest platform for building our software indexes, cwhich requires a lot of math and memory operations. c c --- with bzero --- c Linux$ time ./malloc_test c *# c real0m37.640s c user0m1.370s c sys 0m2.950s c Linux$ c c FreeBSD$ time ./malloc_test c *# c real0m46.640s c user0m2.280s c sys 0m2.550s c FreeBSD$ c c --- without bzero --- c Linux$ time ./malloc_test c *# c real0m6.371s c user0m0.450s c sys 0m1.510s c Linux$ c c FreeBSD$ time ./malloc_test c *# c real0m11.571s c user0m1.150s c sys 0m1.830s c FreeBSD$ c c c c -- c Dimitar Peikov c Programmer Analyst c Globalization Group c We Build e-Business c c RILA Solutions c 27 Building, Acad.G.Bonchev Str. c 1113 Sofia, Bulgaria c c phone: (+359 2) 9797320 c phone: (+359 2) 9797300 c fax: (+359 2) 9733355 c http://www.rila.com c c c cTo Unsubscribe: send mail to [EMAIL PROTECTED] cwith unsubscribe freebsd-hackers in the body of the message c -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: XFree86 4.2.0 GeForce4 440 Go in Dell Latitude C840
On Fri, 31 May 2002 [EMAIL PROTECTED] wrote: Sorry for X off topic... Is anybody here got that combination running? I've seen that Linux world did that with Nvidia's help. How to port their solution into freebsd 4.5 box? After a little searching on the net I found a nv.tar.gz that builds a XF86 module that happens to work on my Dell 8200. Perhaps it works also with the C840. If you can't find it, I can send it to you harti Thanks in advance for any possible help, Igor ua3qrz To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Installing headers and man pages for kmods
Hi there, is there a canonical way to do this? Some time ago the ability to install man pages was removed from kmod.mk. This is reasonable for the system itself, but for third party packages this either forces one to poke in the internals of /usr/share/mk (not an exciting experience) or to fit the source layout to the one expected by the system. The latter is not so nice if you have let's say 6 netgraph nodes, each one with a header file and a man page. You get the c files in 6 per node directories, the man pages in another directory, the header files in a third one. Given, that they are strongly related to each other this is rather unfortunate. At the moment I managed it to include the relevant make file (bsd.man.mk and bsd.incs.mk) from Makefile.inc, but as I suppose, this possibility may be removed at any time. Given that this seems to work, wouldn't it be possible to remove the bsd.init.mk check from those files, so that they can be included from Makefile? Regards, harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Comments on pmake diffs for building on Linux
On Tue, 4 Mar 2008, M. Warner Losh wrote: MWLIn message: [EMAIL PROTECTED] MWLGiorgos Keramidas [EMAIL PROTECTED] writes: MWL: On 2008-03-04 15:38, Robert Watson [EMAIL PROTECTED] wrote: MWL: On Tue, 4 Mar 2008, M. Warner Losh wrote: MWL: MWL: : In most ports of FreeBSD parts to Linux that I've seen, the preferred solution MWL: : has to been to bring the entire FreeBSD queue.h with you rather than relying MWL: : on the native Linux queue.h. This is what we do for OpenBSM, for example; MWL: : this also helps out when you get to Mac OS X, Solaris, etc, where all the MWL: : queue.h's continue to vary in subtle ways. This depends a fair amount on a MWL: : lack of header pollution in the OS's own include files, of course... MWL: MWL: I was rather hoping for something that could be used without any of that MWL: nonsense... MWL: MWL: Sadly, nonsense seems to be the name of the game in software portability. MWL: Here's the broken autoconf garbage I use to pick out adequate queue.h's MWL: from inadequate ones: MWL: MWL: # sys/queue.h exists on most systems, but its capabilities vary a great deal. MWL: # test for LIST_FIRST and TAILQ_FOREACH_SAFE, which appears to not exist in MWL: # all of them, and are necessary for OpenBSM. MWL: AC_TRY_LINK([ MWL: #include sys/queue.h MWL: ], [ MWL: MWL: #ifndef LIST_FIRST MWL: #error LIST_FIRST missing MWL: #endif MWL: #ifndef TAILQ_FOREACH_SAFE MWL: #error TAILQ_FOREACH_SAFE MWL: #endif MWL: ], [ MWL: AC_DEFINE(HAVE_FULL_QUEUE_H,, Define if queue.h includes LIST_FIRST) MWL: ]) MWL: MWL: Note that there are at least a couple of mostly stylistic bugs there (could MWL: use compile rather than link, definition description is poor, errors are MWL: inconsistent). :-) I found that on both Linux and Mac OS X, the queue.h's MWL: didn't have everything I wanted. MWL: MWL: Nice! Thank you Robert. Can I copy parts of this and add them to the MWL: autoconf glue I'm adding now? MWL: MWL: To test just cpp(1) stuff, autoconf supports AC_PREPROC_IFELSE() too, MWL: which I used when I tried writing a check for __FBSDID(): MWL: MWL: AC_PREPROC_IFELSE( MWL: [AC_LANG_PROGRAM([[#include sys/cdefs.h MWL: #ifndef __FBSDID MWL: #error No __FBSDID definition. MWL: #endif]])], MWL: [AC_DEFINE([HAVE_FBSDID_MACRO], [1], MWL:[Define to 1 if you have the __FBSDID macro.])]) MWL: MWL: I can probably improve a bit the queue.h check using what you wrote MWL: above and AC_PREPROC_IFELSE(). MWL MWLThe alternative to uglifying the make sources with #ifdefs would be to MWLjust always use the compat includes when building... No autoconf MWLneeded, and minimal changes to the base make, if any. Yes, please, please don't put #ifdefs into make. It took months to get rid of the cruft that was there and to make it at least somewhat readable. A single compat.h or whatever header file plus, maybe a compat.c file should be sufficient. They can, of course, contain ifdefs. Just include compat.h in all make's c-files. harti ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Popen and EVFILT_WRITE question
On Mon, 31 Mar 2008, Dag-Erling Smrgrav wrote: DSMel [EMAIL PROTECTED] writes: DS DSEV_SET(changes[0], fileno(proc), EVFILT_WRITE, EV_ADD|EV_ENABLE, 0, DS0, 0); DSEV_SET(changes[1], fileno(proc), EVFILT_READ, EV_ADD|EV_ENABLE, 0, DS0, 0); DS DSThis is never going to work. DS DSFirst, the second kevent overrides the first, because they both have the DSsame ident. Why is that so? The man page states that the kevent is identified by the (ident, filter) pair. This would also make more sense, because with bi-directional descriptors (sockets or so) you might want to 'select' on read and write. harti ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kerberized CIFS client?
On Tue, 3 Jun 2008, Derek Taylor wrote: DTOn Thu, 22 May 2008, Hartmut Brandt wrote: DTDerek Taylor wrote: DT This question was previously posed of the freebsd-questions list, but DT with no response for a week, I'd like to try my luck here. If there's DT any more information I should include, please speak up: I would be glad DT to oblige. DT DT I would like to use smb/cifs with kerberos auth, but mount_smbfs doesn't DT seem to support this. DT DT Is anyone aware of an alternate means of performing a mount via smb/cifs DT or any patches to provide such functionality? DT DT I already have smbclient working with -k, but I am also interested in a DT mount. DT DTTry smbnetfs from ports. It's fuse based and seems to work very nice. If DTyou have a large amount of shares floating in your network you want to DTrestrict it to mount only the needed shares via the config file. DTOtherwise it will mount what it can find... DT DTIt plays nicely with kerberors. When your ticket expires you immediately DTloose access; when you renew it you gain access again. All without the DTneed to unmount/mount. Just call smbnetfs once you have your ticket. You DTmay even do this from your .profile. DT DTharti DT DTSorry for not replying sooner. DT DTInitial tests here are promising (I can see some mount paths being DTexported from the server), but it's not fully working (I don't see all DTof the mount paths that *should* be exported and I get permission denied DTerrors). My thoughts are leaning towards an issue in negotiating auth DTwith the server -- perhaps my krb creds aren't being used? You can test this easily: if your ticket expires you get permission denied errors when you try to look into the mounted directories. As soon as you renew the ticket you get access again. All without restarting smbnetfs. harti ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Google Summer of Code 2010 ideas
Hi, On Fri, 19 Mar 2010, Atis wrote: A2) SCPS, Space Communication Protocol Standards AThis is probably my first project choice if all goes well. Space Aprotocols - this sounds very cool :) and is related to my research Ainterests (IP protocols over lossy networks). The first question is - Ado these protocols also have some practical value? This is not-so-new Afamily of protocols, but it seems that very few implementations exist. AOn the one hand, this could be a good thing, because now there a Achance for FreeBSD to be the first OS with open source SCPS Aimplementation. On the other hand - lack of use seems to imply lack of Aimportance and usefulness. The second question - is complete Aimplementation of all the protocols supposed? At first glance it seem Athat e.g. SCPS Security Protocol simply duplicates the functionality Aalready present in IPSec. Still, support for all protocols may be Aneeded for interoperability and completeness of the implementation. AAlso, the amount of work required for this project is very unclear at Athe moment. Acctually the definition of these protocols has been taken over by CCSDS (ccsds.org). I think they are now in some of the green or blue books (cannot remember the color). There is some heavy push in the satellite community on moving towards CCSDS protocols so, for sure, there is practical value in the corresponding communities. I cannot answer the question to what extend an implementation is required. I know that we have some activity in the lower layers and that the upper layers are also used (file transfer, for example). Don't know about networking and security, though. harti ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Google Summer of Code 2010 ideas
On Fri, 19 Mar 2010, Atis wrote: AOn Fri, Mar 19, 2010 at 4:25 PM, Harti Brandt hartmut.bra...@dlr.de wrote: A Hi, A A On Fri, 19 Mar 2010, Atis wrote: A A A2) SCPS, Space Communication Protocol Standards A AThis is probably my first project choice if all goes well. Space A Aprotocols - this sounds very cool :) and is related to my research A Ainterests (IP protocols over lossy networks). The first question is - A Ado these protocols also have some practical value? This is not-so-new A Afamily of protocols, but it seems that very few implementations exist. A AOn the one hand, this could be a good thing, because now there a A Achance for FreeBSD to be the first OS with open source SCPS A Aimplementation. On the other hand - lack of use seems to imply lack of A Aimportance and usefulness. The second question - is complete A Aimplementation of all the protocols supposed? At first glance it seem A Athat e.g. SCPS Security Protocol simply duplicates the functionality A Aalready present in IPSec. Still, support for all protocols may be A Aneeded for interoperability and completeness of the implementation. A AAlso, the amount of work required for this project is very unclear at A Athe moment. A A Acctually the definition of these protocols has been taken over by CCSDS A (ccsds.org). I think they are now in some of the green or blue books A (cannot remember the color). There is some heavy push in the satellite A community on moving towards CCSDS protocols so, for sure, there is A practical value in the corresponding communities. I cannot answer the A question to what extend an implementation is required. I know that we have A some activity in the lower layers and that the upper layers are also used A (file transfer, for example). Don't know about networking and security, A though. A A harti A A AThanks for the reply. Looks like I will cross this project out from my list. AI have found that there is even a reference implementation of SCPS protocols: Ahttp://www.openchannelsoftware.com/projects/SCPS. AIt's usable from FreeBSD too, because they have implemented everything Ain userspace, probably to achieve portability. I wonder whether it Awould make sense to rewrite it or some parts of it (TCP performace Aenchancing proxy is the interesting one) for kernel mode. ATheoretically, that should mean better latency, and no data copy Aoverheads, right? But then again, satellite link bandwidths probably Aare too small to make such improvements important. PEPs are a big issue for the satellite people. With DVB-S2 over a 40MHz transponder you can get 60-80MBit/s if you have good whether. With a RTT of 600ms or more getting TCP to an acceptable speed gets quite tricky. Of course not all people can afford a full transponder, but even a shared link DVB-S2 + RCS requires tuning... I don't know what bitrate you can get in a Docsis system, but I would assume that it is comparable. There are also a lot of commercial users of different VSAT systems, but I have no idea what the share of FreeBSD is in these systems. harti ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Hello!
On Wed, 28 Apr 2010, Brandon Gooch wrote: On Wed, Apr 28, 2010 at 4:04 PM, Stanislav uzunchev.stanis...@gmail.com wrote: Hello! I am accepted for the google summer of code. I just wanted to introduce myself to the community. I will be working on BSNMP enhancement: A new module. I will be very thankful to anyone who have ideas to share. I am still newbie and have never coded for project such FreeBSD, but i hope that with some help i will cope with the project. I will post a link to the wiki page soon. Best regards, to all the people who help somehow to the FreeBSD idea. Congratulations. Nice to hear. Perhaps I finally need to put up the bsnmp repo somewhere. harti ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Non-POSIX compliant pmake with secondary expansion?
Hi Garret, On Wed, 30 Jun 2010, Garrett Cooper wrote: GCI currently set: GC GC.POSIX= I think this should be actually a target (the first one in the Makefile): .POSIX: GC GCIn a Makefile thinking that it would enable only POSIX GCfunctionality, and was fidgeting around with the Makefile trying to GCget it to work. In short, I used secondary expansion, it worked, then GCcompared the output from gmake and it failed (because they have the GC.SECONDEXPANSION keyword). POSIX doesn't mention secondary expansion, GCso obviously it's not a POSIX feature. GCSo I was wondering if secondary expansion is enabled by default GCwith .POSIX instead of being disabled like it should on pmake? I remember that .POSIX does almost nothing (it switches of auto-makefile-dependency processing, set the %POSIX variable and disables banners for parallel makes). This is because of the way processing works in our make. I had Posix-compatibility of make on my list for some time but dropped it. This would require large rewrites of the code. Even the parser would need to be different because there are subtle differences. harti GCThanks, GC-Garrett GC GC$ cat test_Makefile GC.POSIX= GC GCTARGETS= GC GCall: $$(TARGETS) GC GCTARGETS+=idontexist GC GCidontexist: GC @echo $@ GC$ make -f test_Makefile all GCidontexist GC$ gmake -f test_Makefile GCgmake: *** No rule to make target `$(TARGETS)', needed by `all'. Stop. GC$ uname -a GCFreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r206173M: GCMon Apr 26 22:45:06 PDT 2010 GCr...@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA.ata amd64 GC___ GCfreebsd-hackers@freebsd.org mailing list GChttp://lists.freebsd.org/mailman/listinfo/freebsd-hackers GCTo unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org GC GC ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Querying bsnmpd through /var/run/snmpd.sock
On Sun, 23 Jan 2011, Eugene Grosbein wrote: EGbsnmpd running with mibII module opens local socket /var/run/snmpd.sock EGmentioned in snmp_mibII(3) manual page: EG EG The mibII module opens a socket that is used to execute all network EG related ioctl(2) functions. This socket is globally available under the EG name mib_netsock. EG EGHow do I use the socket? I hope to be able to call mib_find_if_sys() function EGfrom another process using the socket. Is there a documentation for this? The socket works just like a UDP socket with the additional plus that the daemon knows whether you're root or not. As I said in my previous mail, easiest would be to implement an additional table with the sysindex as index and ifIndex as a row. harti ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kqueue timer timeout period
On Wed, 11 Jul 2012, Peter Jeremy wrote: PJOn 2012-Jul-10 10:03:08 -0500, Paul Albrecht albre...@glccom.com wrote: PJI have a question about the kqueue timer timeout period ... what's data PJsupposed to be? I thought it was supposed to be the period in PJmilliseconds, but I seem to off by one. PJ PJFor example, if I set date (the timeout period) to 20 milliseconds, I PJoften wait 21 milliseconds which is very undesirable for my application. PJ PJFreeBSD is not a real-time OS. The timeouts specified in various PJsyscalls (eg kevent(EVFILT_TIMER), nanosleep(), select(), poll()) PJspecify minimum timeouts. Once the timeout (rounded up to the next PJtick) has expired, the process will be placed back into the queue PJof processes eligible to be run by the scheduler - which may impose PJa further arbitrary delay. PJ PJPeriodic timers are somewhat better behaved: Scheduler delays only PJimpact process scheduling after the timeout expires and the average PJrate should be very close to that requested. While it is certainly true that FreeBSD is not a real-time OS, this does not explain the timer problems. 2 or 3 month ago I did a simple test with select and poll: I observed a systematic error of about 3-5% of the waiting time. So when you wait for 20ms, you may get 21ms (if running with a low HZ value) because of rounding. But if you wait for 100s, you get 103 or even 105s on a completly idle machine (all services disabled). I think that this is not a problem with beeing non-realtime, but a problem with time-keeping. Shouldn't it be possible to do this better? harti ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
