From owner-freebsd-arch Sun Dec 30 1: 8:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.oxxfordinfo.com (mail.oxxfordinfo.com [216.0.86.67]) by hub.freebsd.org (Postfix) with ESMTP id 2407437B417 for ; Sun, 30 Dec 2001 01:08:42 -0800 (PST) Received: from smtp-gw-4.msn.com (0-1pool69-205.nas2.houston2.tx.us.da.qwest.net [63.232.69.205]) by mail.oxxfordinfo.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZZMQT9J8; Sun, 30 Dec 2001 04:07:55 -0500 Message-ID: <00007b73134e$00005580$000046d6@smtp-gw-4.msn.com> To: From: teeniesuckathon3r8v424@msn.com Subject: TWO GIRLS AND YOU (FREE) QOIDSS Date: Sun, 30 Dec 2001 01:04:35 -2000 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG

To get off this list click here To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 30 8:12:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id A52BA37B417 for ; Sun, 30 Dec 2001 08:12:22 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fBUGCKD94824 for ; Sun, 30 Dec 2001 11:12:20 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 30 Dec 2001 11:12:20 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Subject: Re: adding cred argument to socreate(), making NFS connect using , mount-time credential In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Updated version of the patch that neglects to leak a credential per NFS unmount and per NFS mount failure. :-) Otherwise unchanged, and I plan to commit tomorrow. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services ==== //depot/vendor/freebsd/sys/dev/streams/streams.c#3 (text+ko) - //depot/user/rwatson/mountcred/sys/dev/streams/streams.c#2 (text+ko) ==== content @@ -264,7 +264,8 @@ if ((error = falloc(td, &fp, &fd)) != 0) return error; - if ((error = socreate(family, &so, type, protocol, td)) != 0) { + if ((error = socreate(family, &so, type, protocol, + td->td_proc->p_ucred, td)) != 0) { p->p_fd->fd_ofiles[fd] = 0; ffree(fp); return error; ==== //depot/vendor/freebsd/sys/fs/fifofs/fifo_vnops.c#4 (text+ko) - //depot/user/rwatson/mountcred/sys/fs/fifofs/fifo_vnops.c#2 (text+ko) ==== content @@ -174,14 +174,16 @@ if ((fip = vp->v_fifoinfo) == NULL) { MALLOC(fip, struct fifoinfo *, sizeof(*fip), M_VNODE, M_WAITOK); vp->v_fifoinfo = fip; - error = socreate(AF_LOCAL, &rso, SOCK_STREAM, 0, ap->a_td); + error = socreate(AF_LOCAL, &rso, SOCK_STREAM, 0, + ap->a_td->td_proc->p_ucred, ap->a_td); if (error) { free(fip, M_VNODE); vp->v_fifoinfo = NULL; return (error); } fip->fi_readsock = rso; - error = socreate(AF_LOCAL, &wso, SOCK_STREAM, 0, ap->a_td); + error = socreate(AF_LOCAL, &wso, SOCK_STREAM, 0, + ap->a_td->td_proc->p_ucred, ap->a_td); if (error) { (void)soclose(rso); free(fip, M_VNODE); ==== //depot/vendor/freebsd/sys/fs/portalfs/portal_vnops.c#2 (text+ko) - //depot/user/rwatson/mountcred/sys/fs/portalfs/portal_vnops.c#2 (text+ko) ==== content @@ -246,7 +246,8 @@ /* * Create a new socket. */ - error = socreate(AF_UNIX, &so, SOCK_STREAM, 0, ap->a_td); + error = socreate(AF_UNIX, &so, SOCK_STREAM, 0, + ap->a_td->td_proc->p_ucred, ap->a_td); if (error) goto bad; ==== //depot/vendor/freebsd/sys/kern/uipc_socket.c#9 (text+ko) - //depot/user/rwatson/mountcred/sys/kern/uipc_socket.c#2 (text+ko) ==== content @@ -137,11 +137,12 @@ * closed with soclose(). */ int -socreate(dom, aso, type, proto, td) +socreate(dom, aso, type, proto, cred, td) int dom; struct socket **aso; register int type; int proto; + struct ucred *cred; struct thread *td; { register struct protosw *prp; @@ -172,7 +173,7 @@ TAILQ_INIT(&so->so_incomp); TAILQ_INIT(&so->so_comp); so->so_type = type; - so->so_cred = crhold(td->td_proc->p_ucred); + so->so_cred = crhold(cred); so->so_proto = prp; soref(so); error = (*prp->pr_usrreqs->pru_attach)(so, proto, td); ==== //depot/vendor/freebsd/sys/kern/uipc_syscalls.c#5 (text+ko) - //depot/user/rwatson/mountcred/sys/kern/uipc_syscalls.c#3 (text+ko) ==== content @@ -132,7 +132,8 @@ if (error) goto done2; fhold(fp); - error = socreate(uap->domain, &so, uap->type, uap->protocol, td); + error = socreate(uap->domain, &so, uap->type, uap->protocol, + td->td_proc->p_ucred, td); if (error) { if (fdp->fd_ofiles[fd] == fp) { fdp->fd_ofiles[fd] = NULL; @@ -478,10 +479,12 @@ int fd, error, sv[2]; mtx_lock(&Giant); - error = socreate(uap->domain, &so1, uap->type, uap->protocol, td); + error = socreate(uap->domain, &so1, uap->type, uap->protocol, + td->td_proc->p_ucred, td); if (error) goto done2; - error = socreate(uap->domain, &so2, uap->type, uap->protocol, td); + error = socreate(uap->domain, &so2, uap->type, uap->protocol, + td->td_proc->p_ucred, td); if (error) goto free1; error = falloc(td, &fp1, &fd); ==== //depot/vendor/freebsd/sys/netgraph/ng_ksocket.c#6 (text+ko) - //depot/user/rwatson/mountcred/sys/netgraph/ng_ksocket.c#2 (text+ko) ==== content @@ -586,7 +586,8 @@ return (EINVAL); /* Create the socket */ - error = socreate(family, &priv->so, type, protocol, td); + error = socreate(family, &priv->so, type, protocol, + td->td_proc->p_ucred, td); if (error != 0) return (error); ==== //depot/vendor/freebsd/sys/netsmb/smb_trantcp.c#2 (text+ko) - //depot/user/rwatson/mountcred/sys/netsmb/smb_trantcp.c#2 (text+ko) ==== content @@ -226,7 +226,8 @@ struct socket *so; int error, s; - error = socreate(AF_INET, &so, SOCK_STREAM, IPPROTO_TCP, td); + error = socreate(AF_INET, &so, SOCK_STREAM, IPPROTO_TCP, + td->td_proc->p_ucred, td); if (error) return error; nbp->nbp_tso = so; ==== //depot/vendor/freebsd/sys/nfsclient/bootp_subr.c#4 (text+ko) - //depot/user/rwatson/mountcred/sys/nfsclient/bootp_subr.c#3 (text+ko) ==== content @@ -586,7 +586,8 @@ /* * Create socket and set its recieve timeout. */ - error = socreate(AF_INET, &so, SOCK_DGRAM, 0, td); + error = socreate(AF_INET, &so, SOCK_DGRAM, 0, td->td_proc->p_ucred, + td); if (error != 0) goto out; @@ -971,7 +972,8 @@ struct ifaddr *ifa; struct sockaddr_dl *sdl; - error = socreate(AF_INET, &ifctx->so, SOCK_DGRAM, 0, td); + error = socreate(AF_INET, &ifctx->so, SOCK_DGRAM, 0, + td->td_proc->p_ucred, td); if (error != 0) panic("nfs_boot: socreate, error=%d", error); ==== //depot/vendor/freebsd/sys/nfsclient/krpc_subr.c#3 (text+ko) - //depot/user/rwatson/mountcred/sys/nfsclient/krpc_subr.c#2 (text+ko) ==== content @@ -215,7 +215,8 @@ /* * Create socket and set its recieve timeout. */ - if ((error = socreate(AF_INET, &so, SOCK_DGRAM, 0, td))) + if ((error = socreate(AF_INET, &so, SOCK_DGRAM, 0, + td->td_proc->p_ucred, td))) goto out; tv.tv_sec = 1; ==== //depot/vendor/freebsd/sys/nfsclient/nfs_socket.c#6 (text+ko) - //depot/user/rwatson/mountcred/sys/nfsclient/nfs_socket.c#4 (text+ko) ==== content @@ -162,7 +162,7 @@ nmp->nm_so = (struct socket *)0; saddr = nmp->nm_nam; error = socreate(saddr->sa_family, &nmp->nm_so, nmp->nm_sotype, - nmp->nm_soproto, td); + nmp->nm_soproto, nmp->nm_cred, td); if (error) goto bad; so = nmp->nm_so; ==== //depot/vendor/freebsd/sys/nfsclient/nfs_vfsops.c#9 (text+ko) - //depot/user/rwatson/mountcred/sys/nfsclient/nfs_vfsops.c#5 (text+ko) ==== content @@ -92,7 +92,8 @@ static int nfs_iosize(struct nfsmount *nmp); static void nfs_decode_args(struct nfsmount *nmp, struct nfs_args *argp); static int mountnfs(struct nfs_args *, struct mount *, - struct sockaddr *, char *, char *, struct vnode **); + struct sockaddr *, char *, char *, struct vnode **, + struct ucred *cred); static int nfs_mount(struct mount *mp, char *path, caddr_t data, struct nameidata *ndp, struct thread *td); static int nfs_unmount(struct mount *mp, int mntflags, struct thread *td); @@ -377,6 +378,7 @@ nfs_mountroot(struct mount *mp) { struct mount *swap_mp; + struct nfsmount *nmp = VFSTONFS(mp); struct nfsv3_diskless *nd = &nfsv3_diskless; struct socket *so; struct vnode *vp; @@ -419,7 +421,8 @@ * Do enough of ifconfig(8) so that the critical net interface can * talk to the server. */ - error = socreate(nd->myif.ifra_addr.sa_family, &so, SOCK_DGRAM, 0, td); + error = socreate(nd->myif.ifra_addr.sa_family, &so, SOCK_DGRAM, 0, + nmp->nm_cred, td); if (error) panic("nfs_mountroot: socreate(%04x): %d", nd->myif.ifra_addr.sa_family, error); @@ -557,7 +560,8 @@ mp->mnt_kern_flag = 0; mp->mnt_flag = mountflag; nam = dup_sockaddr((struct sockaddr *)sin, 1); - if ((error = mountnfs(args, mp, nam, which, path, vpp)) != 0) { + if ((error = mountnfs(args, mp, nam, which, path, vpp, td->td_ucred)) + != 0) { printf("nfs_mountroot: mount %s on %s: %d", path, which, error); mp->mnt_vfc->vfc_refcount--; vfs_unbusy(mp, td); @@ -785,7 +789,7 @@ if (error) return (error); args.fh = nfh; - error = mountnfs(&args, mp, nam, path, hst, &vp); + error = mountnfs(&args, mp, nam, path, hst, &vp, td->td_ucred); return (error); } @@ -794,7 +798,7 @@ */ static int mountnfs(struct nfs_args *argp, struct mount *mp, struct sockaddr *nam, - char *pth, char *hst, struct vnode **vpp) + char *pth, char *hst, struct vnode **vpp, struct ucred *cred) { struct nfsmount *nmp; struct nfsnode *np; @@ -814,6 +818,7 @@ } vfs_getnewfsid(mp); nmp->nm_mountp = mp; + nmp->nm_cred = crhold(cred); /* * V2 can only handle 32 bit filesizes. A 4GB-1 limit may be too @@ -891,6 +896,7 @@ return (0); bad: nfs_disconnect(nmp); + crfree(nmp->nm_cred); zfree(nfsmount_zone, nmp); FREE(nam, M_SONAME); return (error); @@ -925,6 +931,7 @@ nfs_disconnect(nmp); FREE(nmp->nm_nam, M_SONAME); + crfree(nmp->nm_cred); zfree(nfsmount_zone, nmp); return (0); } ==== //depot/vendor/freebsd/sys/nfsclient/nfsmount.h#2 (text+ko) - //depot/user/rwatson/mountcred/sys/nfsclient/nfsmount.h#3 (text+ko) ==== content @@ -53,6 +53,7 @@ u_char nm_fh[NFSX_V3FHMAX]; /* File handle of root dir */ int nm_fhsize; /* Size of root file handle */ struct socket *nm_so; /* Rpc socket */ + struct ucred *nm_cred; /* Cached mount-time credential */ int nm_sotype; /* Type of socket */ int nm_soproto; /* and protocol */ int nm_soflags; /* pr_flags for socket protocol */ ==== //depot/vendor/freebsd/sys/sys/socketvar.h#9 (text+ko) - //depot/user/rwatson/mountcred/sys/sys/socketvar.h#2 (text+ko) ==== content @@ -383,7 +383,7 @@ int soconnect __P((struct socket *so, struct sockaddr *nam, struct thread *td)); int soconnect2 __P((struct socket *so1, struct socket *so2)); int socreate __P((int dom, struct socket **aso, int type, int proto, - struct thread *td)); + struct ucred *cred, struct thread *td)); int sodisconnect __P((struct socket *so)); void sofree __P((struct socket *so)); int sogetopt __P((struct socket *so, struct sockopt *sopt)); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 30 17:54:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 893CA37B405; Sun, 30 Dec 2001 17:54:04 -0800 (PST) Received: from dialup-209.245.132.248.dial1.sanjose1.level3.net ([209.245.132.248] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16KreE-0003j7-00; Sun, 30 Dec 2001 17:53:54 -0800 Message-ID: <3C2FC535.DC7F4641@mindspring.com> Date: Sun, 30 Dec 2001 17:53:57 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Mike Smith , arch@freebsd.org Subject: Re: 64 bit counters References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > > AAARGGGHHHH > > On Wed, 26 Dec 2001, Mike Smith wrote: > > > Better would be to architect a solution that works universally. You can > > Architect. Noun.. A person. > Design. Verb Definition install failed at 3. PS: "It's not cyberspace until you can torture someone to death in it, and they die in the real world." -- William Gibson -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 30 18:50:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 1AD5E37B41D; Sun, 30 Dec 2001 18:50:56 -0800 (PST) Received: from dialup-209.245.132.248.dial1.sanjose1.level3.net ([209.245.132.248] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16KsXP-0003EM-00; Sun, 30 Dec 2001 18:50:55 -0800 Message-ID: <3C2FD293.DA31AC4D@mindspring.com> Date: Sun, 30 Dec 2001 18:50:59 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Watson Cc: arch@FreeBSD.org Subject: Re: adding cred argument to socreate(), making NFS connect using , mount-time credential References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Robert Watson wrote: > > Attached please find a diff that does the following: > > (1) Makes the credential used by socreate() an explicit argument to > socreate(), rather than getting it implicitly from the thread > argument. This prevents you from running connections to completion at interrupt, in that it assumes that all calls will be down. The correct way to handle this in the "accept at interrupt" case is to simply clone the credential off the listen socket, instead. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 30 19:22:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 4A26937B41E for ; Sun, 30 Dec 2001 19:22:53 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fBV3MnD00626; Sun, 30 Dec 2001 22:22:49 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 30 Dec 2001 22:22:49 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Terry Lambert Cc: arch@FreeBSD.org Subject: Re: adding cred argument to socreate(), making NFS connect using , mount-time credential In-Reply-To: <3C2FD293.DA31AC4D@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 30 Dec 2001, Terry Lambert wrote: > Robert Watson wrote: > > > > Attached please find a diff that does the following: > > > > (1) Makes the credential used by socreate() an explicit argument to > > socreate(), rather than getting it implicitly from the thread > > argument. > > This prevents you from running connections to completion at interrupt, > in that it assumes that all calls will be down. > > The correct way to handle this in the "accept at interrupt" case is to > simply clone the credential off the listen socket, instead. Actually, socreate() does not appear to be used for the receiving end of the socket code: sonewconn() directly clones features of the listen socket into the accept socket. socreate() appears only to be used in the "outgoing" (down) direction. The only conceptual exception is socketpair(), but since the process gets both ends... This patch won't run into the problem, however. In fact, just a few weejs ago, I fixed the socket code to do precisely what you say: previously, it selected the credential based on one of thread (if available) and listen socket. This inconsistency caused great suffering, so I changed it to consistently clone the listen socket credential, for the reason you describe. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 30 19:26:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 3859037B42A; Sun, 30 Dec 2001 19:26:17 -0800 (PST) Received: from dialup-209.245.132.248.dial1.sanjose1.level3.net ([209.245.132.248] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Kt5c-00001p-00; Sun, 30 Dec 2001 19:26:16 -0800 Message-ID: <3C2FDADC.34FD3714@mindspring.com> Date: Sun, 30 Dec 2001 19:26:20 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Watson Cc: arch@FreeBSD.org Subject: Re: adding cred argument to socreate(), making NFS connect using , mount-time credential References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Robert Watson wrote: > In fact, just a few weejs ago, I fixed the socket code to do precisely > what you say: previously, it selected the credential based on one of > thread (if available) and listen socket. This inconsistency caused great > suffering, so I changed it to consistently clone the listen socket > credential, for the reason you describe. Well, uh, never mind... 8-). I'm moderately offline right now; I should have checked the new code out. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 31 1:38:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from espresso.q9media.com (espresso.q9media.com [216.254.138.122]) by hub.freebsd.org (Postfix) with ESMTP id BEC6137B42A; Mon, 31 Dec 2001 01:38:49 -0800 (PST) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id fBV9aXO55673; Mon, 31 Dec 2001 04:36:33 -0500 (EST) (envelope-from mike) Date: Mon, 31 Dec 2001 04:36:33 -0500 From: Mike Barcroft To: Peter Pentchev Cc: Mike Smith , arch@freebsd.org Subject: kldload(2) family (was Re: loadable aio) Message-ID: <20011231043633.E45114@espresso.q9media.com> References: <20011230215630.B45114@espresso.q9media.com> <200112310508.fBV58MI03596@mass.dis.org> <20011231034807.D45114@espresso.q9media.com> <20011231105940.B3512@straylight.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011231105940.B3512@straylight.oblivion.bg>; from roam@ringlet.net on Mon, Dec 31, 2001 at 10:59:40AM +0200 Organization: The FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [Moved to -arch, BCC'd to -hackers.] Peter Pentchev writes: > Okay, so it's not documented in the manual, but one look at the source > should suffice :) :( > As Mike said, there is a search path. However, the current directory > is tried first. If a file by that name is not found in the current > directory, the search path is, well, searched ;) The search path > is available in the kern.module_path sysctl or in the output of > 'kldconfig -r'. Oh no, it's worse than I feared. > This is similar to what shells have been doing for decades, with > the added feature of an implicit '.' at the start of the search path. Yes, the usual approach shells take is much better designed. Here's how I would design this interface: o _kldload(2) accepts a file path (similar to open(2)) o kldunload(2) accepts a filename (no path) o kldload(3) accepts a module name (procfs), file name (procfs.ko), or file path (/boot/kernel/procfs.ko). o Search paths for kldload(3) are controlled by the environment variable `KLDPATH' (similar to MANPATH and PATH). o When kldload(3) locates a module file, it calls _kldload(2). o kldload(8) uses kldload(3) o kldunload(8) uses kldunload(2) The main advantage of this design is that it allows a Unix programmer to utilize it. :) Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 31 4:28: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from straylight.ringlet.net (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id 8C2A937B426 for ; Mon, 31 Dec 2001 04:27:56 -0800 (PST) Received: (qmail 70611 invoked by uid 1000); 31 Dec 2001 11:56:53 -0000 Date: Mon, 31 Dec 2001 13:56:53 +0200 From: Peter Pentchev To: Mike Barcroft Cc: Mike Smith , arch@freebsd.org Subject: Re: kldload(2) family (was Re: loadable aio) Message-ID: <20011231135653.A40563@straylight.oblivion.bg> Mail-Followup-To: Mike Barcroft , Mike Smith , arch@freebsd.org References: <20011230215630.B45114@espresso.q9media.com> <200112310508.fBV58MI03596@mass.dis.org> <20011231034807.D45114@espresso.q9media.com> <20011231105940.B3512@straylight.oblivion.bg> <20011231043633.E45114@espresso.q9media.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011231043633.E45114@espresso.q9media.com>; from mike@freebsd.org on Mon, Dec 31, 2001 at 04:36:33AM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Dec 31, 2001 at 04:36:33AM -0500, Mike Barcroft wrote: > [Moved to -arch, BCC'd to -hackers.] > > Peter Pentchev writes: > > Okay, so it's not documented in the manual, but one look at the source > > should suffice :) > > :( > > > As Mike said, there is a search path. However, the current directory > > is tried first. If a file by that name is not found in the current > > directory, the search path is, well, searched ;) The search path > > is available in the kern.module_path sysctl or in the output of > > 'kldconfig -r'. > > Oh no, it's worse than I feared. I hope you've seen my follow-up, in which I corrected my gross mistake. There is no current directory; the situation is actually absolutely equivalent to the approach shells take. If you specify a full path name, _kldload(2) loads that file; if you specify just a file name, _kldload(2) searches the path. > > This is similar to what shells have been doing for decades, with > > the added feature of an implicit '.' at the start of the search path. > > Yes, the usual approach shells take is much better designed. It is used here, too; sorry for the confusion that I caused. > Here's how I would design this interface: > o _kldload(2) accepts a file path (similar to open(2)) > o kldunload(2) accepts a filename (no path) > o kldload(3) accepts a module name (procfs), file name (procfs.ko), or > file path (/boot/kernel/procfs.ko). > o Search paths for kldload(3) are controlled by the environment > variable `KLDPATH' (similar to MANPATH and PATH). > o When kldload(3) locates a module file, it calls _kldload(2). > o kldload(8) uses kldload(3) > o kldunload(8) uses kldunload(2) > > The main advantage of this design is that it allows a Unix programmer > to utilize it. :) The main problem with this design, as I see it, is that it is highly centered around userland programs. There are many cases when kernel code needs to load a module - as a very simple example, consider module dependencies or the case of the initial kernel booting and preloaded modules :) (remember, the kernel itself is also a module) Kernel code has no concept of 'environment' (or rather, should not need to have any); thus, the search path needs to reside in the kernel. It does now, in the form of a sysctl, which also allows userland code to examine and/or change it, either by sysctl(8), or by kldconfig(8). The current design (as far as I understand it) goes something like: o linker_search_path(9) accepts a module name (procfs), file name (procfs.ko) or file path (/boot/kernel/procfs.ko). o Search paths for linker_search_path(9) are controlled by the kernel variable linker_path, exported as the kern.modules_path sysctl. o _kldload(2) uses linker_search_path(9) o kldunload(2) accepts a file ID, obtained from a call to kldfind(2) o kldload(3) uses _kldload(2) o kldload(8) uses kldload(3) o kldunload(8) uses kldfind(2) and kldunload(2) Okay, so the kldfind/kldunload part is somewhat weird, but once you accept that the kernel, too, needs to load modules (without any kind of information as to a running process and the environment thereof), the _kldload(2) and linker_search_path(9) path seems to become as clear as it could be :) G'luck, Peter -- This sentence no verb. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 31 4:55:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id B829337B425 for ; Mon, 31 Dec 2001 04:55:34 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id XAA27818; Mon, 31 Dec 2001 23:55:20 +1100 Date: Mon, 31 Dec 2001 23:55:10 +1100 (EST) From: Bruce Evans X-X-Sender: To: Alfred Perlstein Cc: Michal Mertl , Matthew Dillon , Subject: Re: 64 bit counters In-Reply-To: <20011229185917.J16101@elvis.mu.org> Message-ID: <20011231234620.O6481-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 29 Dec 2001, Alfred Perlstein wrote: > * Michal Mertl [011229 18:49] wrote: > > I doesn't seem too bad to me, but I do have a problem - I can't implement > > real atomic 64 bit operations on an i386. It shouldn't be named atomic_XXX > > if it isn't atomic. So that other people don't start to use it on <586 > > with some variable which changes fast. > > > > What about making the counters not 64 bit, but the size of biggest atomic > > type? Something like type u_maxatomic_t which would be 32 bit on <586 and > > 64 bit otherwise. There would still be problem in determining at compile > > time the size but we could choose the safe size if not somewhere defined > > otherwise. > > > > I can make changes to my local tree but how should I send them someone for > > review? Should I send them to arch? I tried to find the answer to this > > question in developers's handbook but didn't find it. > > *laff* the concept of atomic_t was initially proposed by me over > a year ago (i got the idea from linux) however it never seemed to > get done. atomic_t would be "int" if anything. I removed support for atomic operations on all types except "int" (and some pointers punned to int on i386's), and found that (on i386's) only 2 source files didn't compile. Both are easy to fix (one MD place used a char type for a set of flags that is followed by padding to a 32-bit boundary anyway, and one MI place uses long types which are equivalent to ints on i386's anyway). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 31 5:41:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from prg.traveller.cz (prg.traveller.cz [193.85.2.77]) by hub.freebsd.org (Postfix) with ESMTP id 5AF4637B42F for ; Mon, 31 Dec 2001 05:41:32 -0800 (PST) Received: from prg.traveller.cz (localhost [127.0.0.1]) by prg.traveller.cz (8.12.1[KQ-CZ](1)/8.12.1/pukvis) with ESMTP id fBVDfQlk033352; Mon, 31 Dec 2001 14:41:26 +0100 (CET) Received: from localhost (mime@localhost) by prg.traveller.cz (8.12.1[KQ-CZ](1)/pukvis) with ESMTP id fBVDfQLb033349; Mon, 31 Dec 2001 14:41:26 +0100 (CET) Date: Mon, 31 Dec 2001 14:41:26 +0100 (CET) From: Michal Mertl To: Bruce Evans Cc: Alfred Perlstein , Matthew Dillon , Subject: Re: 64 bit counters In-Reply-To: <20011231234620.O6481-100000@gamplex.bde.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 31 Dec 2001, Bruce Evans wrote: > On Sat, 29 Dec 2001, Alfred Perlstein wrote: > > > * Michal Mertl [011229 18:49] wrote: > > > I doesn't seem too bad to me, but I do have a problem - I can't implement > > > real atomic 64 bit operations on an i386. It shouldn't be named atomic_XXX > > > if it isn't atomic. So that other people don't start to use it on <586 > > > with some variable which changes fast. > > > > > > What about making the counters not 64 bit, but the size of biggest atomic > > > type? Something like type u_maxatomic_t which would be 32 bit on <586 and > > > 64 bit otherwise. There would still be problem in determining at compile > > > time the size but we could choose the safe size if not somewhere defined > > > otherwise. > > > > > > I can make changes to my local tree but how should I send them someone for > > > review? Should I send them to arch? I tried to find the answer to this > > > question in developers's handbook but didn't find it. > > > > *laff* the concept of atomic_t was initially proposed by me over > > a year ago (i got the idea from linux) however it never seemed to > > get done. > > atomic_t would be "int" if anything. I removed support for atomic > operations on all types except "int" (and some pointers punned to int > on i386's), and found that (on i386's) only 2 source files didn't > compile. Both are easy to fix (one MD place used a char type for a > set of flags that is followed by padding to a 32-bit boundary anyway, > and one MI place uses long types which are equivalent to ints on i386's > anyway). > I've almost finished the changes to implement interface counters with atomic_t which is either 32 bit or 64 bit. I'll finish it anyway. It can at least be converted to atomic_add_int (instead of my WIP name atomic_add_max and friends) and it will help someone later to be able to get rid of giant protection. I may be wrong even with this - well if that's going to be the case and otherwise there will be no use for my changes, they can always be forgotten. I could take it as practice lesson on hacking kernel sources :-). > Bruce > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > -- Michal Mertl mime@traveller.cz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 31 7:24:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tomts19-srv.bellnexxia.net (tomts19.bellnexxia.net [209.226.175.73]) by hub.freebsd.org (Postfix) with ESMTP id DFC2837B41B; Mon, 31 Dec 2001 07:24:15 -0800 (PST) Received: from xena.gsicomp.on.ca ([199.243.148.182]) by tomts19-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20011231152415.WZUB9690.tomts19-srv.bellnexxia.net@xena.gsicomp.on.ca>; Mon, 31 Dec 2001 10:24:15 -0500 Received: from localhost (matt@localhost) by xena.gsicomp.on.ca (8.11.1/8.11.1) with ESMTP id fBVFECH36688; Mon, 31 Dec 2001 10:14:13 -0500 (EST) (envelope-from matt@xena.gsicomp.on.ca) Date: Mon, 31 Dec 2001 10:14:12 -0500 (EST) From: Matthew Emmerton To: Mike Barcroft Cc: Peter Pentchev , Mike Smith , arch@FreeBSD.ORG Subject: Re: kldload(2) family (was Re: loadable aio) In-Reply-To: <20011231043633.E45114@espresso.q9media.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 31 Dec 2001, Mike Barcroft wrote: > [Moved to -arch, BCC'd to -hackers.] > > Peter Pentchev writes: > > Okay, so it's not documented in the manual, but one look at the source > > should suffice :) > > :( > > > As Mike said, there is a search path. However, the current directory > > is tried first. If a file by that name is not found in the current > > directory, the search path is, well, searched ;) The search path > > is available in the kern.module_path sysctl or in the output of > > 'kldconfig -r'. > > Oh no, it's worse than I feared. > > > This is similar to what shells have been doing for decades, with > > the added feature of an implicit '.' at the start of the search path. > > Yes, the usual approach shells take is much better designed. > > Here's how I would design this interface: > o _kldload(2) accepts a file path (similar to open(2)) > o kldunload(2) accepts a filename (no path) > o kldload(3) accepts a module name (procfs), file name (procfs.ko), or > file path (/boot/kernel/procfs.ko). > o Search paths for kldload(3) are controlled by the environment > variable `KLDPATH' (similar to MANPATH and PATH). > o When kldload(3) locates a module file, it calls _kldload(2). > o kldload(8) uses kldload(3) > o kldunload(8) uses kldunload(2) > > The main advantage of this design is that it allows a Unix programmer > to utilize it. :) Doesn't using an environment variable (KLDPATH) introduce all of the issues surrounding the use of LD_LIBRARY_PATH on Solaris and other OSes? While it's not the same issues (KLDs vs shared libraries), it still introduces the possibility of interesting exploits and problems, especially for installations that load as much as possible from KLDs. With the search path controlled by a sysctl, you have to be root to change it. With an environment variable, Joe User could blow it away, and then hammer the help desk with cries of "why can't I mount my floppy/cdrom" or "my sound card doesn't work" or "PPPoE doesn't work" - all because of a bogus KLD search path. I would think that using the root-controlled sysctl first, then using the user-controlled KLDPATH second would be a less error-prone setup. Please cc me since I'm not on arch-. -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 31 7:40:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from straylight.ringlet.net (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id 7DCA637B42B for ; Mon, 31 Dec 2001 07:40:34 -0800 (PST) Received: (qmail 76022 invoked by uid 1000); 31 Dec 2001 14:57:41 -0000 Date: Mon, 31 Dec 2001 16:57:41 +0200 From: Peter Pentchev To: Matthew Emmerton Cc: Mike Barcroft , Mike Smith , arch@FreeBSD.ORG Subject: Re: kldload(2) family (was Re: loadable aio) Message-ID: <20011231165741.A475@straylight.oblivion.bg> Mail-Followup-To: Matthew Emmerton , Mike Barcroft , Mike Smith , arch@FreeBSD.ORG References: <20011231043633.E45114@espresso.q9media.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from matt@gsicomp.on.ca on Mon, Dec 31, 2001 at 10:14:12AM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Dec 31, 2001 at 10:14:12AM -0500, Matthew Emmerton wrote: [snip] > > Doesn't using an environment variable (KLDPATH) introduce all of the > issues surrounding the use of LD_LIBRARY_PATH on Solaris and other > OSes? While it's not the same issues (KLDs vs shared libraries), it still > introduces the possibility of interesting exploits and problems, > especially for installations that load as much as possible from KLDs. > > With the search path controlled by a sysctl, you have to be root to change > it. With an environment variable, Joe User could blow it away, and then > hammer the help desk with cries of "why can't I mount my > floppy/cdrom" or "my sound card doesn't work" or "PPPoE doesn't work" - > all because of a bogus KLD search path. > > I would think that using the root-controlled sysctl first, then using the > user-controlled KLDPATH second would be a less error-prone setup. Security is one of the issues. Another one, as pointed out in my e-mail to -arch, is the fact that sometimes the kernel itself needs to load modules. The kernel has no notion of 'environment', and even if it had, it would be.. interesting.. to have it choose which process's environment to use - sometimes there is simply no currently running process. Thus, since kernel module loading is, well, a kernel issue, IMHO the path belongs in the kernel and in the kernel only; that is, a kernel variable exported by the kern.modules_path sysctl. G'luck, Peter -- This sentence contains exactly threee erors. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 31 8:23: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 9309B37B41F; Mon, 31 Dec 2001 08:22:51 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id DAA05958; Tue, 1 Jan 2002 03:22:49 +1100 Date: Tue, 1 Jan 2002 03:22:40 +1100 (EST) From: Bruce Evans X-X-Sender: To: Mike Barcroft Cc: Peter Pentchev , Mike Smith , Subject: Re: kldload(2) family (was Re: loadable aio) In-Reply-To: <20011231043633.E45114@espresso.q9media.com> Message-ID: <20020101025947.L6989-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 31 Dec 2001, Mike Barcroft wrote: > [Moved to -arch, BCC'd to -hackers.] > > Peter Pentchev writes: > > Okay, so it's not documented in the manual, but one look at the source > > should suffice :) > > :( > > > As Mike said, there is a search path. However, the current directory > > is tried first. If a file by that name is not found in the current > > directory, the search path is, well, searched ;) The search path > > is available in the kern.module_path sysctl or in the output of > > 'kldconfig -r'. > > Oh no, it's worse than I feared. I recently noticed some more brokenness related to this. The following commit: RCS file: /home/ncvs/src/sys/conf/kmod.mk,v Working file: kmod.mk head: 1.109 ... ---------------------------- revision 1.106 date: 2001/08/08 13:51:10; author: green; state: Exp; lines: +2 -2 In the KLD "load" make target, don't load using the "absolute" path of "./foo.ko". Use "/full/path/foo.ko" instead so that when the path is reported as being an absolute path to the "shared library", at least it's not really a relative path. Obtained from: LOMAC/FreeBSD project ---------------------------- perfectly breaks "make load" for the usual case where there is a separate obj directory, by using a wrong absolute path (one involving ${.CURDIR} instead of ${.OBJDIR}. There was some discussion of the brokenness in followup to this commit. Relative paths like "foo.ko" should work in the Unix way IMO (the "./" in "./foo.ko" was apparently a failed attempt to prevent searching like it would in the shell). The syscall should not do any searching, especially not in a misdesigned undocumented insecure search path with DOS-style separators. > > This is similar to what shells have been doing for decades, with > > the added feature of an implicit '.' at the start of the search path. > > Yes, the usual approach shells take is much better designed. > > Here's how I would design this interface: > o _kldload(2) accepts a file path (similar to open(2)) > o kldunload(2) accepts a filename (no path) > o kldload(3) accepts a module name (procfs), file name (procfs.ko), or > file path (/boot/kernel/procfs.ko). > o Search paths for kldload(3) are controlled by the environment > variable `KLDPATH' (similar to MANPATH and PATH). > o When kldload(3) locates a module file, it calls _kldload(2). > o kldload(8) uses kldload(3) > o kldunload(8) uses kldunload(2) > > The main advantage of this design is that it allows a Unix programmer > to utilize it. :) I would intentionally leave out kldload(3). There is a problem converting relative names to absolute ones for auto-loading things like filesystems in the kernel, but there is no problem in userland -- the modules are wherever you installed or built them. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 31 12:40: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id 65AAB37B439 for ; Mon, 31 Dec 2001 12:39:26 -0800 (PST) Received: (qmail 2761 invoked from network); 31 Dec 2001 20:39:24 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 31 Dec 2001 20:39:24 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 31 Dec 2001 12:39:13 -0800 (PST) From: John Baldwin To: Michal Mertl Subject: Re: 64 bit counters Cc: arch@FreeBSD.ORG, Matthew Dillon , Alfred Perlstein , Bruce Evans Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 31-Dec-01 Michal Mertl wrote: > On Mon, 31 Dec 2001, Bruce Evans wrote: > >> On Sat, 29 Dec 2001, Alfred Perlstein wrote: >> >> > * Michal Mertl [011229 18:49] wrote: >> > > I doesn't seem too bad to me, but I do have a problem - I can't >> > > implement >> > > real atomic 64 bit operations on an i386. It shouldn't be named >> > > atomic_XXX >> > > if it isn't atomic. So that other people don't start to use it on <586 >> > > with some variable which changes fast. >> > > >> > > What about making the counters not 64 bit, but the size of biggest >> > > atomic >> > > type? Something like type u_maxatomic_t which would be 32 bit on <586 >> > > and >> > > 64 bit otherwise. There would still be problem in determining at compile >> > > time the size but we could choose the safe size if not somewhere defined >> > > otherwise. >> > > >> > > I can make changes to my local tree but how should I send them someone >> > > for >> > > review? Should I send them to arch? I tried to find the answer to this >> > > question in developers's handbook but didn't find it. >> > >> > *laff* the concept of atomic_t was initially proposed by me over >> > a year ago (i got the idea from linux) however it never seemed to >> > get done. >> >> atomic_t would be "int" if anything. I removed support for atomic >> operations on all types except "int" (and some pointers punned to int >> on i386's), and found that (on i386's) only 2 source files didn't >> compile. Both are easy to fix (one MD place used a char type for a >> set of flags that is followed by padding to a 32-bit boundary anyway, >> and one MI place uses long types which are equivalent to ints on i386's >> anyway). >> > > I've almost finished the changes to implement interface counters with > atomic_t which is either 32 bit or 64 bit. I'll finish it anyway. It can > at least be converted to atomic_add_int (instead of my WIP name > atomic_add_max and friends) and it will help someone later to be able to > get rid of giant protection. I may be wrong even with this - well if > that's going to be the case and otherwise there will be no use for my > changes, they can always be forgotten. I could take it as practice lesson > on hacking kernel sources :-). I really need to fix the atomic(9) API to use sizeof() instead of explicit types like Bruce wants. :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 31 15:41:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id E447137B41B; Mon, 31 Dec 2001 15:41:13 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id A2F6981D03; Mon, 31 Dec 2001 17:41:13 -0600 (CST) Date: Mon, 31 Dec 2001 17:41:13 -0600 From: Alfred Perlstein To: re@freebsd.org Cc: arch@freebsd.org Subject: xfree4 by default? Message-ID: <20011231174113.O16101@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG What is the proceedure one must follow to present xfree4 as the new default? It's been around for a long time and support a LOT more chipsets a lot better. Can we go ahead and just pull some switch or are there more sinister issues involved? -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 31 15:43:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id BD81437B417 for ; Mon, 31 Dec 2001 15:43:30 -0800 (PST) Received: (qmail 23601 invoked from network); 31 Dec 2001 23:43:29 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 31 Dec 2001 23:43:29 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20011231174113.O16101@elvis.mu.org> Date: Mon, 31 Dec 2001 15:43:19 -0800 (PST) From: John Baldwin To: Alfred Perlstein Subject: RE: xfree4 by default? Cc: arch@freebsd.org, re@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 31-Dec-01 Alfred Perlstein wrote: > What is the proceedure one must follow to present xfree4 as the new > default? It's been around for a long time and support a LOT more > chipsets a lot better. Can we go ahead and just pull some switch > or are there more sinister issues involved? The last time I and others brought this up to Jordan, the tentative plan was to switch for 5.0. At this point in the game it is probably a bit late for 4.5, however, if you want to head up an effort to get test port builds done after the release with 4 as the default and get people to test it out then perhaps a switch could be done for 4.6. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 31 16:23:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mao.stokely.org (mao.stokely.org [65.84.64.228]) by hub.freebsd.org (Postfix) with ESMTP id 374DE37B41F; Mon, 31 Dec 2001 16:22:38 -0800 (PST) Received: by mao.stokely.org (Postfix, from userid 2074) id B97014B65D; Mon, 31 Dec 2001 16:22:22 -0800 (PST) Date: Mon, 31 Dec 2001 16:22:22 -0800 From: Murray Stokely To: John Baldwin Cc: Alfred Perlstein , arch@freebsd.org, re@freebsd.org Subject: Re: xfree4 by default? Message-ID: <20011231162222.V2286@windriver.com> References: <20011231174113.O16101@elvis.mu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="/unnNtmY43mpUSKx" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Mon, Dec 31, 2001 at 03:43:19PM -0800 X-GPG-Key-ID: 1024D/0E451F7D X-GPG-Key-Fingerprint: E2CA 411D DD44 53FD BB4B 3CB5 B4D7 10A2 0E45 1F7D Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --/unnNtmY43mpUSKx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Dec 31, 2001 at 03:43:19PM -0800, John Baldwin wrote: > The last time I and others brought this up to Jordan, the tentative plan was to > switch for 5.0. At this point in the game it is probably a bit late for 4.5, > however, if you want to head up an effort to get test port builds done after > the release with 4 as the default and get people to test it out then perhaps a > switch could be done for 4.6. I agree that we should make the switch in -STABLE immediately after FreeBSD 4.5 is released. Every other x86 Unix I've been exposed to has been using X4 for over a year. The arguments about older supported hardware do not hold water any more since X4 supports so many newer chipsets out of the box that X336 can't handle. - Murray --/unnNtmY43mpUSKx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQE8MQE9tNcQog5FH30RAtVIAKC3twr4JyjyeRFDBHySZne3lmK28ACeJ3QS 7jA3krand305ypYjvkIdXMc= =Et70 -----END PGP SIGNATURE----- --/unnNtmY43mpUSKx-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 31 16:32:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id 80EB937B419; Mon, 31 Dec 2001 16:32:43 -0800 (PST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.6) id g010Wew04479; Tue, 1 Jan 2002 01:32:40 +0100 (CET) (envelope-from wkb) Date: Tue, 1 Jan 2002 01:32:40 +0100 From: Wilko Bulte To: Murray Stokely Cc: John Baldwin , Alfred Perlstein , arch@FreeBSD.ORG, re@FreeBSD.ORG Subject: Re: xfree4 by default? Message-ID: <20020101013240.B4434@freebie.xs4all.nl> References: <20011231174113.O16101@elvis.mu.org> <20011231162222.V2286@windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011231162222.V2286@windriver.com>; from murray@FreeBSD.ORG on Mon, Dec 31, 2001 at 04:22:22PM -0800 X-OS: FreeBSD 4.5-PRERELEASE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Dec 31, 2001 at 04:22:22PM -0800, Murray Stokely wrote: > On Mon, Dec 31, 2001 at 03:43:19PM -0800, John Baldwin wrote: > > The last time I and others brought this up to Jordan, the tentative plan was to > > switch for 5.0. At this point in the game it is probably a bit late for 4.5, > > however, if you want to head up an effort to get test port builds done after > > the release with 4 as the default and get people to test it out then perhaps a > > switch could be done for 4.6. > > I agree that we should make the switch in -STABLE immediately after > FreeBSD 4.5 is released. Every other x86 Unix I've been exposed to > has been using X4 for over a year. The arguments about older > supported hardware do not hold water any more since X4 supports so > many newer chipsets out of the box that X336 can't handle. Does anybody out there know how well X4 works on the Alpha? Wilko -- | / o / /_ _ email: wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 31 16:39:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.hiwaay.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id 659D537B420; Mon, 31 Dec 2001 16:39:33 -0800 (PST) Received: from bsd.havk.org (user-24-214-88-13.knology.net [24.214.88.13]) by mail.hiwaay.net (8.12.1/8.12.1) with ESMTP id g010dTBZ021695; Mon, 31 Dec 2001 18:39:30 -0600 (CST) Received: by bsd.havk.org (Postfix, from userid 1001) id BC8C11A786; Mon, 31 Dec 2001 18:39:28 -0600 (CST) Date: Mon, 31 Dec 2001 18:39:28 -0600 From: Steve Price To: Murray Stokely Cc: John Baldwin , Alfred Perlstein , arch@freebsd.org, re@freebsd.org Subject: Re: xfree4 by default? Message-ID: <20011231183928.F37696@bsd.havk.org> References: <20011231174113.O16101@elvis.mu.org> <20011231162222.V2286@windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011231162222.V2286@windriver.com>; from murray@FreeBSD.org on Mon, Dec 31, 2001 at 04:22:22PM -0800 X-Operating-System: FreeBSD 4.5-PRERELEASE i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Dec 31, 2001 at 04:22:22PM -0800, Murray Stokely wrote: > > I agree that we should make the switch in -STABLE immediately after > FreeBSD 4.5 is released. Every other x86 Unix I've been exposed to > has been using X4 for over a year. The arguments about older > supported hardware do not hold water any more since X4 supports so > many newer chipsets out of the box that X336 can't handle. All of the recent package builds have been with XFREE86_VERSION=4. I'm not sure how long for sure but for as long as I can remember which isn't saying much. Making it the default shouldn't be all that difficult in bsd.port.mk. Don't know how hard it would be for sysinstall and friends. -steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 31 23:10: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from drone2.qsi.net.nz (drone2-svc-skyt.qsi.net.nz [202.89.128.2]) by hub.freebsd.org (Postfix) with SMTP id 6ED9737B419 for ; Mon, 31 Dec 2001 23:09:57 -0800 (PST) Received: (qmail 52885 invoked by uid 0); 1 Jan 2002 07:09:55 -0000 Received: from unknown (HELO grandpa.ijs.co.nz) ([202.89.142.198]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 1 Jan 2002 07:09:55 -0000 Message-Id: <5.1.0.14.2.20020101180823.02dc8ac0@202.89.128.27> X-Sender: research@202.89.128.27 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 01 Jan 2002 20:09:48 +1300 To: arch@freebsd.org From: Craig Carey Subject: RE: xfree4 by default?, mouse bug In-Reply-To: References: <20011231174113.O16101@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 01.12.31 15:43 -0800 Monday, John Baldwin wrote: > >On 31-Dec-01 Alfred Perlstein wrote: >> What is the proceedure one must follow to present xfree4 as the new >> default? It's been around for a long time and support a LOT more >> chipsets a lot better. Can we go ahead and just pull some switch >> or are there more sinister issues involved? > >The last time I and others brought this up to Jordan, the tentative plan was to >switch for 5.0. At this point in the game it is probably a bit late for 4.5, >however, if you want to head up an effort to get test port builds done after >the release with 4 as the default and get people to test it out then perhaps a >switch could be done for 4.6. > >-- FreeBSD maybe could make updates to version 4.x even when it does not make that version of XFree86 available. The following suggests that. (I doubt it is important to keep up to date since it is a big download and when taken from an XFree86 mirror, it seems to download OK and install OK. Maybe updates to resolve XFree86 bugs could be released if there is no fix from XFree86, KDE, or GNOME. The FreeBSD oscillating mouse that can't easily be positioned over a point XFree86 has a major bug in it. I presume the bug is going to be seen as rather significant by just about any user of FreeBSD. I don't know when a fix might appear. The bug causes this: when trying to move the mouse to a point, it strangely stops short of the desired final point. The user speeds up the mouse, and then strangely the mouse speeds itself up and there is an overshooting. The result is that the pointer oscillates around the final ending point until the user gives it full attention. This feedback problem goes away if the mouse is slowed down a lot. That seem bad and it is not better when it is known that some XFree86 coder accidentally a piecewise linear function to be discontinuous. I tried FreeBSD and quickly concluded the mouse is so badly done that the console mode of FreeBSD is a better environment than KDE's GUI system. The bug in the XFree86 subroutine named "xf86PostMotionEvent()" of file "xf86Xinput.c" (a pow(x,y)function is used when the xset threshold = 0): http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/common/xf86Xinput.c The XFree86 Hewlett Packard code seems have no similar problem (so the XFree86 developers could have copied from HP in the search for a remedy): http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/hp/input/x_hil.c To make it plainer, here is a plot of the function that processes the velocity data from the physical pointer device: Velocity used for the xf86PostMotionEvent() positioning the screen cursor | | / | / | / dx' = accel * dx | / | / | | | | | | | | | | | | | | | | | | | | | _| (case threshold not = 0) | __/ | __/ | __/ | __/ dx' = dx | __/ | / Distance from Endpoint, +----------------------- or the Physical Mouse Speed The two lines don't match up (before 1 Jan 2002). I sent in bug reports to KDE, GNOME, and XFree86, finable with the word "deceleration". Xfree86 seems to have no online bug management system. I don't use FreeBSD's GUI because of the bug, but now I have a way out which is to recompile XFree86. Anybody serious about FreeBSD would currently maybe want to recompile XFree86 v4, which is a ground for not making available binary releases of XFree86 version 4. Craig Carey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message