Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

freebsd-hackers-digest V5 #732

0 views

Skip to first unread message

owner-freebsd-...@freebsd.org

unread,

Feb 28, 2003, 10:43:44 AM2/28/03

freebsd-hackers-digest Friday, February 28 2003 Volume 05 : Number 732

In this issue:
RE: Jail seperation patch
Re: Jail seperation patch
Disk scheduling in FreeBSD
RE: Disk scheduling in FreeBSD
Re: Disk scheduling in FreeBSD
Re: Disk scheduling in FreeBSD
Re: Disk scheduling in FreeBSD
64 bit endian routines
Re: 64 bit endian routines
Re: Disk scheduling in FreeBSD
wierdness on 4.7-RELEASE++ X11
Re: 64 bit endian routines
Re: [correction] wierdness on 4.7-RELEASE++ X11
Re: 64 bit endian routines
Re: 64 bit endian routines
Re: C coding editor
Re: [Solution] wierdness on 4.7-RELEASE++ X11
Re: 64 bit endian routines
Re: C coding editor
RE: Disk scheduling in FreeBSD
RE: Disk scheduling in FreeBSD
Question about divert in ipfw2 on 5.0 release
Re: Question about divert in ipfw2 on 5.0 release
Re: 64 bit endian routines
kern/40611 linux compatibility fix
Re: C coding editor

----------------------------------------------------------------------

Date: Thu, 27 Feb 2003 07:16:15 -0800
From: "Mooneer Salem" <moo...@translator.cx>
Subject: RE: Jail seperation patch

Hello,

Actually, I just gave it blah.lifeafterking.org in /etc/hosts. 10.0.0.4
really *is* in the same jail:

%ifconfig
lnc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 10.0.0.3 netmask 0xffffffff broadcast 10.0.0.3
inet 10.0.0.4 netmask 0xffffffff broadcast 10.0.0.4
ether 00:50:56:e0:26:54
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
%hostname
test.lifeafterking.org
%

As for the hide files code, I found a possible location for it, in
vfs_subr.c (extattr_check_cred()). I added
this block to it:

/* Check to make sure outside user can actually access jailed files */
if (cred->cr_prison && cred->cr_uid != 0 && jail_hide_files) {
LIST_FOREACH(element, &firstjail, pointers) {
if (element->pr == cred->cr_prison) {
break;
}
}

if (!strncmp(element->chroot_path,
vp->v_mount->mnt_stat.f_mntonname,
strlen(element->chroot_path)) {
return (EPERM);
}
}

This ensures the check is only run if the sysctl variable equals 1.

Thanks,

- --
Mooneer Salem
GPLTrans: http://www.translator.cx/
lifeafterking.org: http://www.lifeafterking.org/

- -----Original Message-----
From: owner-free...@FreeBSD.ORG
[mailto:owner-free...@FreeBSD.ORG]On Behalf Of Pawel Jakub Dawidek
Sent: Thursday, February 27, 2003 1:43 AM
To: Mooneer Salem
Cc: FreeBSD Hackers
Subject: Re: Jail seperation patch

On Wed, Feb 26, 2003 at 02:48:25PM -0800, Mooneer Salem wrote:
+> 1. It handles at least case 1 just fine:
+>
+> %telnet 10.0.0.2 25
+> Trying 10.0.0.2...
+> Connected to pacific.lifeafterking.org.
[...]
+> %telnet 10.0.0.3 25
+> Trying 10.0.0.3...
+> Connected to test.lifeafterking.org..
[...]
+> %telnet 10.0.0.4 25
+> Trying 10.0.0.4...
+> Connected to blah.lifeafterking.org..

Nope, this is incorrect behaviour. INADDR_ANY in jail means: 10.1.1.2 or
10.1.1.3, but not 10.1.1.4.

+> 2. Neat. :) I'm going to add sysctls when I get a chance for the mount
+> hiding. Also, I'm going to take a look
+> at the VFS code and see if I can hide files from non-root non-jailed
users.

??? Everything that you can check IMHO is to check every parent directory
of opened file if it isn't equal to jail chroot directory.
But this is slow and stupid, because there could be many jails with shared
chroot directory.

+> 3. Does multi-level jailing add any further restrictions to the jails
within
+> the jails, besides the standard ones
+> imposed?

Nope, but jail runned in jail can't use IPs that aren't binded to parent
jail and securelevels are checked recursively.

- --
Pawel Jakub Dawidek
UNIX Systems Administrator
http://garage.freebsd.pl
Am I Evil? Yes, I Am.

------------------------------

Date: Thu, 27 Feb 2003 16:43:51 +0100
From: Pawel Jakub Dawidek <ni...@garage.freebsd.pl>
Subject: Re: Jail seperation patch

- --rG09A39trvEtf3rB
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 27, 2003 at 07:16:15AM -0800, Mooneer Salem wrote:
+> Actually, I just gave it blah.lifeafterking.org in /etc/hosts. 10.0.0.4
+> really *is* in the same jail:
+>=20
+> %ifconfig
+> lnc0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
+> inet 10.0.0.3 netmask 0xffffffff broadcast 10.0.0.3
+> inet 10.0.0.4 netmask 0xffffffff broadcast 10.0.0.4
+> ether 00:50:56:e0:26:54
+> lo0: flags=3D8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
+> %hostname
+> test.lifeafterking.org
+> %

Ehh, so now I know nothing about your test settings. After all problems
isn't so trivial.

+> As for the hide files code, I found a possible location for it, in
+> vfs_subr.c (extattr_check_cred()). I added
+> this block to it:
[...]

IMHO very dirty and not complete. Jail don't have to be chrooted to
diferent mount-point, and checks like those should be done between
vnodes, not pathnames.

In my opinion better way is just create another jail and don't give
access to main host for regular users.

- --=20
Pawel Jakub Dawidek
UNIX Systems Administrator
http://garage.freebsd.pl
Am I Evil? Yes, I Am.

- --rG09A39trvEtf3rB
Content-Type: application/pgp-signature
Content-Disposition: inline

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (FreeBSD)

iQCVAwUBPl4yNz/PhmMH/Mf1AQHotQQAkeywMGpBMfwYGhDQccL/QWzbnrFrvWyJ
YV1SE7gTMtBYJNWaqnid7Jb0sY9/kF9aM1ZhVF17zlKpFxvp4+X3FWbHPFpscHMl
wfNDJwrMtu9ISHOqeFxQ9r15ftDdRqQEr5QaWSaOXa/Y8cJKtFBffqdD2qBTVxl4
EKarNg7ptYY=
=8lmk
- -----END PGP SIGNATURE-----

- --rG09A39trvEtf3rB--

------------------------------

Date: Thu, 27 Feb 2003 11:01:40 -0500
From: "" <hi...@unixdaemons.com>
Subject: Disk scheduling in FreeBSD

Hello gang.

Does anyone know what kind of `Disk Scheduling' algorithm,
if any, is used in FreeBSD?

Cheers.

- --
Hiten Pandya
hi...@unixdaemons.com, hi...@uk.FreeBSD.ORG
http://www.unixdaemons.com/~hiten

- -------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

------------------------------

Date: Thu, 27 Feb 2003 16:20:45 -0000
From: "Paul Robinson" <pa...@iconoplex.co.uk>
Subject: RE: Disk scheduling in FreeBSD

Hiten Pandya wrote:

> Hello gang.
>
> Does anyone know what kind of `Disk Scheduling' algorithm,
> if any, is used in FreeBSD?

I'm assuming you've read this recently then:

http://www.kerneltrap.org/node-592.html

Anticipatory Schedulers are all well and good, but I think (I might be
corrected here) that most of the disk I/O work in FreeBSD has been around
softupdates. However, when I read it, and looked at a description of the AS
algo (not the source, I don't want to have any GPL infection around me), I
have to admit, I did eye up /usr/src and my week's holiday the week after
next, just as a bit of fun...

Anybody else got plans on this? I need to have a proper look around the
source tree, but I think this would be both self-contained (i.e. easy to
back out if it breaks) and useful. Quite a small-ish project really as well.

------------------------------

Date: Thu, 27 Feb 2003 18:12:29 +0100
From: p...@phk.freebsd.dk
Subject: Re: Disk scheduling in FreeBSD

In message <1046361700.3...@webmail.unixdaemons.com>, "" writes:
>Hello gang.
>
>Does anyone know what kind of `Disk Scheduling' algorithm,
>if any, is used in FreeBSD?

One way elevator sort.

- --
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

------------------------------

Date: Thu, 27 Feb 2003 11:31:19 -0800
From: David Schultz <d...@FreeBSD.ORG>
Subject: Re: Disk scheduling in FreeBSD

Thus spake Paul Robinson <pa...@iconoplex.co.uk>:
> Hiten Pandya wrote:
>
> > Hello gang.
> >
> > Does anyone know what kind of `Disk Scheduling' algorithm,
> > if any, is used in FreeBSD?
>
> I'm assuming you've read this recently then:
>
> http://www.kerneltrap.org/node-592.html
...
> Anybody else got plans on this? I need to have a proper look around the
> source tree, but I think this would be both self-contained (i.e. easy to
> back out if it breaks) and useful. Quite a small-ish project really as well.

The original anticipatory scheduler implementation was done for
FreeBSD 4.3. See

http://www.cs.rice.edu/~ssiyer/r/antsched/

I haven't looked carefully at it myself; I've only heard about it
through someone who knows Margo Seltzer. It looks very
interesting, although I worry that it would interfere with the
prefetching and sequential heuristics that the VM system already
does (which are already VERY good[1]). Maybe the authors already
thought of that issue and addressed it. So in short, I don't know
much about it, but I think it's worth looking into.

[1] The fact that the improvement Linux got out of the new
approach was so much greater than the improvement FreeBSD 4.3
got out of it is a testament to that fact, I think.

------------------------------

Date: Thu, 27 Feb 2003 20:50:31 +0100
From: p...@phk.freebsd.dk
Subject: Re: Disk scheduling in FreeBSD

In message <20030227193...@HAL9000.homeunix.com>, David Schultz writes:

>> http://www.kerneltrap.org/node-592.html
>...
>> Anybody else got plans on this?

I have plans to make it possible to configure, at run time, which, if
any disksort you want to use on a particular disk device.

------------------------------

Date: Thu, 27 Feb 2003 19:24:49 -0800 (PST)
From: Nate Lawson <n...@FreeBSD.org>
Subject: 64 bit endian routines

First, the simple question: what's the simplest cross-platform way of
implementing scsi_ulto4b and scsi_4btoul (/sys/cam/scsi/scsi_all.h) for
64 bit values. GEOM (/sys/geom/geom_enc.c) implements it via a 64 bit
cast in g_enc_le8. Is this the best current way?

Second, anyone done work on unifying our various byte ordering macros?
Besides htonl and ntohl, there are scsi_*ul*, g_enc_*, openssl/aes_locl.h,
machine/endian.h, arpa/nameser.h, and I'm sure there are others. Perhaps
the best thing is to add macros similar to geom_enc_* to machine/endian.h.
Any ideas?

Thanks,
Nate

------------------------------

Date: Thu, 27 Feb 2003 22:30:58 -0500
From: Mike Barcroft <mi...@FreeBSD.org>
Subject: Re: 64 bit endian routines

Nate Lawson <n...@FreeBSD.org> writes:
> First, the simple question: what's the simplest cross-platform way of
> implementing scsi_ulto4b and scsi_4btoul (/sys/cam/scsi/scsi_all.h) for
> 64 bit values. GEOM (/sys/geom/geom_enc.c) implements it via a 64 bit
> cast in g_enc_le8. Is this the best current way?

Maybe the byteorder(9) macrofunctions with a union?

> Second, anyone done work on unifying our various byte ordering macros?
> Besides htonl and ntohl, there are scsi_*ul*, g_enc_*, openssl/aes_locl.h,
> machine/endian.h, arpa/nameser.h, and I'm sure there are others. Perhaps
> the best thing is to add macros similar to geom_enc_* to machine/endian.h.
> Any ideas?

Most of these could probably be implemented in terms of the __bswap*()
functions in <machine/endian.h>, except for vendor sources like
openssl, and htonl and ntohl which already are. I'm not sure if there
would be an advantage to moving the geom byte ordering functions to
<sys/endian.h> (I guess phk didn't either).

Best regards,
Mike Barcroft

------------------------------

Date: Fri, 28 Feb 2003 04:57:36 +0100 (CET)
From: "=?iso-8859-1?q?Pedro=20F.=20Giffuni?=" <giff...@yahoo.com>
Subject: Re: Disk scheduling in FreeBSD

FWIW,

Although the original anticipatory scheduler prototype
was made for FreeBSD, it cannot be used in the base
system, unless reimplemented, due to the license. I
wonder if the Linux guys redid it or simply didn't
notice.

The option of configuring it for runtime is welcome, I
think.

cheers,

Pedro.

______________________________________________________________________
Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino
http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html

------------------------------

Date: Thu, 27 Feb 2003 20:10:51 -0800 (PST)
From: Julian Elischer <jul...@elischer.org>
Subject: wierdness on 4.7-RELEASE++ X11

I have some new machien s I'm trying to install
and I have been puting 4.7 onto them and using
the X-kern-developer install type.

However X11 cannot start on these machines, even though it wuns
perfectly on some other machines with the same cards..

XFree86 3.3.6 XFree86 4.2.1
Motherboard:
SuperMicro P4D6+ works works

ASUS P4PE fails works

ASUS P4B533 fails works

This is a PCI ATI rage card. We have a stack of them...

The failure mode is wierd.

I'm using the same confg file and X11 tree (exaclty)
on both the P4D6 and the P4PE.

Here is the failure on the P4PE..

ATI Radeon 7500 QW (AGP)
(II) Primary Device is: PCI 02:09:0
(II) ATI: Candidate "Device" section "Card0".
(II) ATI: Shared PCI/AGP Mach64 in slot 2:9:0 detected.
(II) ATI: Shared PCI/AGP Mach64 in slot 2:9:0 assigned to active
"Device" section "Card0".
(II) resource ranges after xf86ClaimFixedResources() call:
[0] -1 0xffe00000 - 0xffffffff (0x200000) MX[B](B)
[1] -1 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
[2] -1 0x000f0000 - 0x000fffff (0x10000) MX[B]
[...]
[19] -1 0x0000d800 - 0x0000d8ff (0x100) IX[B]E
[20] -1 0x0000b400 - 0x0000b4ff (0x100) IX[B](B)
(II) Loading sub module "atimisc"
(II) LoadModule: "atimisc"
(II) Loading /usr/X11R6/lib/modules/drivers/atimisc_drv.o
(II) Module atimisc: vendor="The XFree86 Project"
compiled for 4.2.1, module version = 6.4.8
Module class: XFree86 Video Driver
ABI class: XFree86 Video Driver, version 0.5
(II) resource ranges after probing:
[0] -1 0xffe00000 - 0xffffffff (0x200000) MX[B](B)
[1] -1 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
[2] -1 0x000f0000 - 0x000fffff (0x10000) MX[B]
[3] -1 0x000c0000 - 0x000effff (0x30000) MX[B]
[...]
[24] 0 0x000003b0 - 0x000003bb (0xc) IS[B]
[25] 0 0x000003c0 - 0x000003df (0x20) IS[B]
(II) Setting vga for screen 0.
(==) ATI(0): Chipset: "ati".
(==) ATI(0): Depth 8, (==) framebuffer bpp 8
(II) Loading sub module "int10"
(II) LoadModule: "int10"
(II) Loading /usr/X11R6/lib/modules/libint10.a
(II) Module int10: vendor="The XFree86 Project"
compiled for 4.2.1, module version = 1.0.0
ABI class: XFree86 Video Driver, version 0.5
(==) ATI(0): Write-combining range (0xa0000,0x20000) was already clear
(==) ATI(0): Write-combining range (0xf0000,0x10000)
Symbol xf86DestroyCursorInfoRec from module
/usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved!
Symbol XAADestroyInfoRec from module
/usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved!
Symbol ShadowFBInit from module
/usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved!
Symbol fbPictureInit from module
/usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved!
Symbol fbScreenInit from module
/usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved!
Symbol xf4bppScreenInit from module
/usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved!
Symbol xf1bppScreenInit from module
/usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved!
Symbol xf86SetDDCproperties from module
/usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved!
Symbol xf86PrintEDID from module
/usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved!
Symbol vbeFree from module /usr/X11R6/lib/modules/drivers/atimisc_drv.o
is unresolved!
Symbol vbeDoEDID from module
/usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved!
Symbol VBEInit from module /usr/X11R6/lib/modules/drivers/atimisc_drv.o
is unresolved!
Symbol xf86DestroyCursorInfoRec from module
/usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved!
Symbol xf86InitCursor from module
/usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved!
Symbol xf86CreateCursorInfoRec from module
/usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved!
Symbol XAADestroyInfoRec from module
/usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved!
Symbol XAAInit from module /usr/X11R6/lib/modules/drivers/atimisc_drv.o
is unresolved!
Symbol XAACreateInfoRec from module
/usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved!

Fatal server error:
Caught signal 11. Server aborting

When reporting a problem related to a server crash, please send
the full server output, not just the last messages.
This can be found in the log file "/var/log/XFree86.0.log".
Please report problems to xfr...@xfree86.org.

=================

the Wierd thing is that all these sympols are in some .a files in
/usr/X11R6/lib/modules/

e.g. lets look for XAADestroyInfoRec,

cfgx# cd /usr/X11R6/lib/modules/
cfgx# find . -type f | xargs nm -o | grep XAADestroyInfoRec
./drivers/apm_drv.o: U XAADestroyInfoRec
./drivers/atimisc_drv.o: U XAADestroyInfoRec
./drivers/chips_drv.o: U XAADestroyInfoRec
./drivers/cirrus_alpine.o: U XAADestroyInfoRec
./drivers/cirrus_laguna.o: U XAADestroyInfoRec
./drivers/cyrix_drv.o: U XAADestroyInfoRec
./drivers/glint_drv.o: U XAADestroyInfoRec
./drivers/i128_drv.o: U XAADestroyInfoRec
./drivers/i740_drv.o: U XAADestroyInfoRec
./drivers/i810_drv.o: U XAADestroyInfoRec
./drivers/mga_drv.o: U XAADestroyInfoRec
./drivers/neomagic_drv.o: U XAADestroyInfoRec
./drivers/nv_drv.o: U XAADestroyInfoRec
./drivers/r128_drv.o: U XAADestroyInfoRec
./drivers/radeon_drv.o: U XAADestroyInfoRec
./drivers/rendition_drv.o: U XAADestroyInfoRec
./drivers/s3virge_drv.o: U XAADestroyInfoRec
./drivers/hold/atimisc_drv.o: U XAADestroyInfoRec
./drivers/savage_drv.o: U XAADestroyInfoRec
./drivers/siliconmotion_drv.o: U XAADestroyInfoRec
./drivers/sis_drv.o: U XAADestroyInfoRec
./drivers/tdfx_drv.o: U XAADestroyInfoRec
./drivers/tga_drv.o: U XAADestroyInfoRec
./drivers/trident_drv.o: U XAADestroyInfoRec
./drivers/tseng_drv.o: U XAADestroyInfoRec
./libxaa.a:xaaInit.o:00000024 T XAADestroyInfoRec
cfgx#

So, it's needed in all the drivers. So why does it only matter on one
set of motherboards?

Is there something I can do to make the server include libxaa.a?

------------------------------

Date: Thu, 27 Feb 2003 20:18:49 -0800
From: Marcel Moolenaar <mar...@xcllnt.net>
Subject: Re: 64 bit endian routines

On Thu, Feb 27, 2003 at 10:30:58PM -0500, Mike Barcroft wrote:
>
> Most of these could probably be implemented in terms of the __bswap*()
> functions in <machine/endian.h>, except for vendor sources like
> openssl, and htonl and ntohl which already are. I'm not sure if there
> would be an advantage to moving the geom byte ordering functions to
> <sys/endian.h> (I guess phk didn't either).

The geom functions serve a primary purpose of dealing with random
alignment of fields. The endianness has been added later, so they
now serve a dual function. Do not unify them with byte-order only
functions.

- --
Marcel Moolenaar USPA: A-39004 mar...@xcllnt.net

------------------------------

Date: Thu, 27 Feb 2003 20:34:51 -0800 (PST)
From: Julian Elischer <jul...@elischer.org>
Subject: Re: [correction] wierdness on 4.7-RELEASE++ X11

On Thu, 27 Feb 2003, Julian Elischer wrote:

>
> I have some new machien s I'm trying to install
> and I have been puting 4.7 onto them and using
> the X-kern-developer install type.
>
> However X11 cannot start on these machines, even though it wuns
> perfectly on some other machines with the same cards..
>
> XFree86 3.3.6 XFree86 4.2.1
> Motherboard:
> SuperMicro P4D6+ works works
>
> ASUS P4PE fails works
>
> ASUS P4B533 fails works
>
>
oops that should be:
> XFree86 3.3.6 XFree86 4.2.1
> Motherboard:
> SuperMicro P4D6+ works works
>
> ASUS P4PE works fails
>
> ASUS P4B533 works fails
>

it's the 4.2.1 that fails..

------------------------------

Date: Thu, 27 Feb 2003 20:45:44 -0800 (PST)
From: Nate Lawson <n...@FreeBSD.org>
Subject: Re: 64 bit endian routines

Date: Thu, 27 Feb 2003 20:18:49 -0800
From: Marcel Moolenaar <mar...@xcllnt.net>
To: Mike Barcroft <mi...@FreeBSD.ORG>
Cc: Nate Lawson <n...@FreeBSD.ORG>, cur...@FreeBSD.ORG,
hac...@FreeBSD.ORG
Subject: Re: 64 bit endian routines
References: <200302280324....@freefall.freebsd.org> <2003022722...@espresso.bsdmike.org>

On Thu, Feb 27, 2003 at 10:30:58PM -0500, Mike Barcroft wrote:
> Most of these could probably be implemented in terms of the __bswap*()
> functions in <machine/endian.h>, except for vendor sources like
> openssl, and htonl and ntohl which already are. I'm not sure if there
> would be an advantage to moving the geom byte ordering functions to
> <sys/endian.h> (I guess phk didn't either).

--
Marcel Moolenaar USPA: A-39004 mar...@xcllnt.net

Both scsi and geom implement unaligned access functions that perform byte
ordering. I never intended to supplant them with __bswap*(). What I want
is for machine/endian.h to have functions that provide 16-64 bit endian
conversions in both aligned and unaligned access forms. After these functions
are there, I'd like us to unify use of them and remove driver-private
versions.

Is this more clear now?

- -Nate

------------------------------

Date: Thu, 27 Feb 2003 21:17:13 -0800
From: Marcel Moolenaar <mar...@xcllnt.net>
Subject: Re: 64 bit endian routines

On Thu, Feb 27, 2003 at 08:45:44PM -0800, Nate Lawson wrote:
>
> Both scsi and geom implement unaligned access functions that perform byte
> ordering. I never intended to supplant them with __bswap*(). What I want
> is for machine/endian.h to have functions that provide 16-64 bit endian
> conversions in both aligned and unaligned access forms. After these functions
> are there, I'd like us to unify use of them and remove driver-private
> versions.
>
> Is this more clear now?

Crystal :-)

- --
Marcel Moolenaar USPA: A-39004 mar...@xcllnt.net

------------------------------

Date: Fri, 28 Feb 2003 00:36:40 -0500
From: David Cuthbert <da...@kanga.org>
Subject: Re: C coding editor

Wes Peters wrote:
> Seriously, limiting your programming for a lifetime to 80 columns
> because you couldn't figure out how to make some grotty old dot
> matrix printer do 8-point printing a decade ago really isn't all
> that smart, is it?

No, but I still find 80 columns to be a reasonable limit. The average
person can comfortably track up to about 65 characters on a line in
prose (or so I've been told from a study that was related to me from a
forgotten source...). Given that there's more whitespace in code, it's
probably a bit more.

The 80 column limit can also encourage developers to keep their
functions smaller and factor out common code. (I say can, because I've
seen the six-levels-of-indentation-loops sadly all too often...)

> I'm still disappointed at programming editors that can't make sense
> of normal typefaces and have to be used with monospaced fonts.

I've tried it, mainly to see what it looks like. Unfortunately, the
delimiters that have a great deal of meaning in many languages (parens,
braces, brackets, single quotes, etc.) end up being far too small for my
eyes.

For some reason, though, I've seen a lot of VHDL code typeset in books
in proportional fonts, though usually with boldface highlighting of
reserved words.

------------------------------

Date: Thu, 27 Feb 2003 21:39:37 -0800 (PST)
From: Julian Elischer <jul...@elischer.org>
Subject: Re: [Solution] wierdness on 4.7-RELEASE++ X11

Well there is a small screwup in the XFree86-4.2.1 code that
makes a theoretically optional component non -optional in some hardware
configurations. In the atimisc driver Xaa is not made 'optional'
as it is apparently in other drivers.

The solution is to include a module that we don't need, and which is
supposed to be optional, but is apparently not.

in the config file /etc/X11/XF86Config
at:

Section "Module"
Load "dbe"
Load "dri"
Load "extmod"
Load "glx"
Load "pex5"
Load "record"
Load "xie"
Load "xtrap"
Load "speedo"
Load "type1"
Load "xaa" <--------Add this line
EndSection

It's disconcerting when a -RELEASE system can't get X11 going
on SOME hardware, however at least the answer is simple.

keywords for poor people searching in the future:

ASUS P4PE P4B533 PCI
ati Rage atimisc
XAADestroyInfoRec unresolved

------------------------------

Date: Fri, 28 Feb 2003 07:13:45 +0100
From: "Poul-Henning Kamp" <p...@phk.freebsd.dk>
Subject: Re: 64 bit endian routines

In message <200302280445....@freefall.freebsd.org>, Nate Lawson writ
es:

>Both scsi and geom implement unaligned access functions that perform byte
>ordering. I never intended to supplant them with __bswap*(). What I want
>is for machine/endian.h to have functions that provide 16-64 bit endian
>conversions in both aligned and unaligned access forms. After these functions
>are there, I'd like us to unify use of them and remove driver-private
>versions.

I'm all for a unification. I only made my private version in geom because
I couldn't get any responses when I raised the issue on arch@.

------------------------------

Date: Thu, 27 Feb 2003 23:24:56 -0800
From: Wes Peters <w...@softweyr.com>
Subject: Re: C coding editor

On Wednesday 26 February 2003 09:57 am, Jason Andresen wrote:
> Wes Peters wrote:
>
> > Seriously, limiting your programming for a lifetime to 80 columns
> > because you couldn't figure out how to make some grotty old dot
> > matrix printer do 8-point printing a decade ago really isn't all
> > that smart, is it?
>
> Even if I never have to print out on a printer like that, who's to
> say nobody else is? You will no doubt turn people away if they open
> up your code in their favorite programming editor and all of the
> lines wrap a few characters. Worse if they are already at the
> maximum size their screen/eyeballs can support.

I rejected programming to the least common denominator in equipment.
You should try it too, it's incredibly liberating. The legions of
programmers under the age of 25 holding up 80x25 "consoles" as some
sort of mantra is just weird, and the idea of cramming a video card
capable of a million 3d triangles per second into a machine so some
dumbass can use it as a vt220 just makes me roll on the floor. Of
course you probably didn't live through paying $75,000 for workstations
with a tenth that 3D performance.

> > I'm still disappointed at programming editors that can't make sense
> > of normal typefaces and have to be used with monospaced fonts.
> > Same for email, but that's a different argument.
>
> I find that monospace fonts are quite nice in programming on occasion
> when you want to line up output or just nicely format blocks of text.

My code almost never lines up output for formats blocks of text. For
some odd reason, the program on the other end of the socket doesn't
really care what my source code looks like, so I make it readable and
understandable by using horizontal and vertical whitespace in ways that
separate the code into small, visually recognizable chunks that
implement a single idea at a time.

> What about when someone opens up your project with a different font
> and all of the comments and blocks of code are all scattered across
> the screen in some haphazard looking mess?

I use what is mostly likely a different font from what you use for
coding every day. I do all of my coding on FreeBSD, most of it in
Emacs, and use lucidatypewriter (less and less) or luxi mono for most
of it. My own code often goes as wide as 120 characters because
anything more than that won't fit comfortably on a 1024 pixel wide
screen, which is a much better default than 80 columns these days.

> Visual distinctiveness
> and effective use of whitespace can be invaluble in helping people
> understand your code (or understanding other people's code). That's
> why people have settled on a format they can reproduce in almost all
> instances. Very few compilers accept code with formatting markup
> beyond ^Ls and TABs. You can't compile a Word document.

No, but your editor really ought to be able to interpret tab stops
correctly at like 0.5 in increments. Code editors on the Mac have
been doing this for years.

- --
"Where am I, and what am I doing in this handbasket?"

Wes Peters Softweyr LLC
w...@softweyr.com http://softweyr.com/

------------------------------

Date: Fri, 28 Feb 2003 09:19:10 -0000
From: "Paul Robinson" <pa...@iconoplex.co.uk>
Subject: RE: Disk scheduling in FreeBSD

David Schultz wrote:

> The original anticipatory scheduler implementation was done for
> FreeBSD 4.3. See
>
> http://www.cs.rice.edu/~ssiyer/r/antsched/

Yeah, I managed to grab that 45 seconds after sending my original post. I've
also contacted Sitaram Iyer directly to see how he feels about this heading
into BSD. He seems happy with the idea, and apparently Kirk McKuisck and
Poul-Hamming Kamp have mailed him about it in the past. He likes the idea of
it going under BSD license, but hasn't had time/energy to get it finished
off and incorporated. His precise words were "Help is greatly appreciated
:-)", so help is what he'll jolly well get! :-)

> I haven't looked carefully at it myself; I've only heard about it
> through someone who knows Margo Seltzer. It looks very
> interesting, although I worry that it would interfere with the
> prefetching and sequential heuristics that the VM system already
> does (which are already VERY good[1]). Maybe the authors already
> thought of that issue and addressed it. So in short, I don't know
> much about it, but I think it's worth looking into.

Well, I'm just a hanger-on without a commit bit, so I'll work on making it
production ready in the next few weeks, post up a patch and if somebody
wants to commit it, great. At the moment it's all based on 4.3-RELEASE and
isn't really production ready. It does look worth doing though.

> [1] The fact that the improvement Linux got out of the new
> approach was so much greater than the improvement FreeBSD 4.3
> got out of it is a testament to that fact, I think.

The improvements he got out of FBSD are not to be sniffed at. The paper is
talking about upto 60% performance increase in certain conditions. In
addition, I think the algorithms used can be tweaked to take into account
how FBSD works, and some of the VM stuff can be tweaked to work even better
with this. Or at least, that was my intial thought last night when I was
reading it on the laptop. I know FBSD already rocks on I/O generally, but I
am not adverse to look at producing patches to make it better. :-)

It's going to be the week after next before I start working on this proper,
but I'll let -hackers know when the patches against -CURRENT are ready.

- --
Paul Robinson

------------------------------

Date: Fri, 28 Feb 2003 09:49:23 -0000
From: "Paul Robinson" <pa...@iconoplex.co.uk>
Subject: RE: Disk scheduling in FreeBSD

> FWIW,
>
> Although the original anticipatory scheduler prototype
> was made for FreeBSD, it cannot be used in the base
> system, unless reimplemented, due to the license. I
> wonder if the Linux guys redid it or simply didn't
> notice.
>
> The option of configuring it for runtime is welcome, I
> think.

The license is actually BSD. Or at least, the one I saw last night had a
remarable resemblance to it. :-) The author of the implementation has also
stated in an e-mail to me that he is happy for a BSD-based production-ready
derivative to be produced based on his code.

------------------------------

Date: Fri, 28 Feb 2003 13:10:03 +0300 (MSK)
From: denb <de...@front.ru>
Subject: Question about divert in ipfw2 on 5.0 release

I write program simular to natd, witch receives packets at divert port X.
Question:
On ipfw1 (FreeBSD 4.7) this rules work excellent:

ipfw add divert X from any to any Y
ipfw add divert X from any Y to any

We're diverting all received and sended packets (from\to port Y) to divert port X.
But these rules are not working together with ipfw2 (5.0 Release). Each single rule
works fine, but when i combine them together only first of them triggers. The order
doesn't matter.

What am I doing wrong?

------------------------------

Date: Fri, 28 Feb 2003 15:57:04 +0300 (MSK)
From: Maxim Konovalov <ma...@FreeBSD.org>
Subject: Re: Question about divert in ipfw2 on 5.0 release

Hello,

On 13:10+0300, Feb 28, 2003, denb wrote:

> I write program simular to natd, witch receives packets at divert port X.
> Question:
> On ipfw1 (FreeBSD 4.7) this rules work excellent:
>
> ipfw add divert X from any to any Y
> ipfw add divert X from any Y to any
>
> We're diverting all received and sended packets (from\to port Y) to divert port X.
> But these rules are not working together with ipfw2 (5.0 Release). Each single rule
> works fine, but when i combine them together only first of them triggers. The order
> doesn't matter.
>
> What am I doing wrong?

Can't reproduce:

# ipfw add 1 divert 1111 tcp from any to any 1973
00001 divert 1111 tcp from any to any dst-port 1973
# ipfw add 2 divert 1111 tcp from any 1973 to any
00002 divert 1111 tcp from any 1973 to any
# nc localhost 1973
# nc -p 1973 localhost 21
# ipfw show 1 2
00001 1 60 divert 1111 tcp from any to any dst-port 1973
00002 1 60 divert 1111 tcp from any 1973 to any

What am I doing wrong? :-)

- --
Maxim Konovalov, ma...@macomnet.ru, ma...@FreeBSD.org

------------------------------

Date: Fri, 28 Feb 2003 08:25:25 -0500
From: Mike Barcroft <mi...@FreeBSD.org>
Subject: Re: 64 bit endian routines

Nate Lawson <n...@FreeBSD.org> writes:
> Both scsi and geom implement unaligned access functions that perform byte
> ordering. I never intended to supplant them with __bswap*(). What I want
> is for machine/endian.h to have functions that provide 16-64 bit endian
> conversions in both aligned and unaligned access forms. After these functions
> are there, I'd like us to unify use of them and remove driver-private
> versions.

Sounds good, though <sys/endian.h> would be more appropriate unless
they're MD.

Best regards,
Mike Barcroft

------------------------------

Date: Fri, 28 Feb 2003 13:42:45 +0000
From: Matthew Seaman <m.se...@infracaninophile.co.uk>
Subject: kern/40611 linux compatibility fix

Dear Hackers,

Is there any chance that the patch given in kern/40611 could be
committed to the 4-STABLE tree? It has the desirable effect of making
eg. the linux-sun-jdk14 port usable as a non-root user. This would
appear to my untutored eye to be a sub-set of the differences already
existing between the HEAD and RELENG_4 versions of
src/sys/posix4/p1003_1b.c

Cheers,

Matthew

- --
Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK

------------------------------

Date: Fri, 28 Feb 2003 07:39:59 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: C coding editor

David Cuthbert wrote:
> Wes Peters wrote:
> > Seriously, limiting your programming for a lifetime to 80 columns
> > because you couldn't figure out how to make some grotty old dot
> > matrix printer do 8-point printing a decade ago really isn't all
> > that smart, is it?
>
> No, but I still find 80 columns to be a reasonable limit. The average
> person can comfortably track up to about 65 characters on a line in
> prose (or so I've been told from a study that was related to me from a
> forgotten source...). Given that there's more whitespace in code, it's
> probably a bit more.

Average English word length is 5 characters; with a space, that's
6 characters. 65 characters is therefore 11 words. The Bell Labs
study which set telephone number length limits at 7 digits found
that the average person could keep between 5 and 9 items in memory
at a time. I guess "11 words" isn't out of the question, but it's
a bit long. 8-) 8-).

However... that does mean that something with a shorter average
length is going to limit the desirable maximum line length even
further, if your purpose is "better human comprehension".

> The 80 column limit can also encourage developers to keep their
> functions smaller and factor out common code. (I say can, because I've
> seen the six-levels-of-indentation-loops sadly all too often...)

Seems to have worked well for tcp_input(). 8-) 8-).

> > I'm still disappointed at programming editors that can't make sense
> > of normal typefaces and have to be used with monospaced fonts.
>
> I've tried it, mainly to see what it looks like. Unfortunately, the
> delimiters that have a great deal of meaning in many languages (parens,
> braces, brackets, single quotes, etc.) end up being far too small for my
> eyes.
>
> For some reason, though, I've seen a lot of VHDL code typeset in books
> in proportional fonts, though usually with boldface highlighting of
> reserved words.

Proportional fonts are much slower reading than non-proportional;
it is also harder to get the clock marks in the paper tape, punch
cards, and printer spacing charts to line up correctly. 8^p.

- -- Terry

------------------------------

End of freebsd-hackers-digest V5 #732
*************************************

To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-hackers-digest in the body of the message

0 new messages