Re: Copyright Contradiction in libalias
On Wed, Aug 22, 2001 at 09:23:58 +1000, Andrew Kenneth Milton wrote: Once it's in the Public Domain you have abandoned your claim to copyright. That is the point of the Public Domain. If you still wish to retain the copyright and the associated rights you cannot release it into the Public Domain. No. Copyright consist in two parts. First one is who is the author. Second one is what is usage/modification/publishing/etc. permissions. If you create some work, you are an author and no act including your owns can deattach author rights from you. And if you put it in Public Domain you, as author, grant anybody do anything with it. The Public Domain is not a license, it is an abandonment of copyright. No, author part of copyright can't be deattached, unless fraud happens. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Userbase of -current
On Tue, 21 Aug 2001, Jonathan Chen wrote: On Sun, Aug 19, 2001 at 08:27:21AM -1000, Vincent Poy wrote: Or, simply unplug the harddrive from your laptop and plug it into another machine to do the install. When I fubar'ed my laptop's fs not too long ago, I hot-plugged my laptop harddrive into my desktop, issued an atacontrol reinit, and proceeded to merrily run sysinstall under a chroot. Of course, this is by no means the proper way, but it gets the job done... This idea will work since I can always use the notebook hDD with the adapter to the desktop but what does the atacontrol reinit do exactly since couldn't I just do a fresh install and just move the drive? atacontrol allows for hot-swapping of ata devices. Don't worry about it if you just plan on installing the laptop drive and turning on the computer. It'll act like any other normal drive. Sounds pretty cool. Except the laptop in the desktop idea won't work as I have a PPPoE based DSL connection and my Windows desktop is the current LAN router which will be replaced by the FreeBSD machine. Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
KSE threading report
Well I have reached milestone 2 I have a kernel in which teh 'struct proc' pointers have been replaced wherever needed with struct thread pointers and where the process structure ahs been split to create 4 substructures. At this stage I can get to multi-user mode but it doesn't last too far into make buildworld Networking seems to generally work as I can use NFS and ssh. Thsi kernel has most of the infrastructure changes needed to support threading, but all teh crucial code has not been rewritten, meaning that there is a lot of code that assumes 1 thread per process. The diffs are at http://www.freebsd.org/~julian/ and are at present 1835905 bytes Having reached this milestone it is now feasible for others to help.. things that others can do: someone with an alpha can make the analogous changes in the alpha code as to those I made in i386 (I have already done some) ditto for powerPC and Ia64. send me diffs or get peter to set you up with a perforce account on freefall and commit them yourself. the aim is to get to multiuser the same as i386, not to get threads going (yet) If someone wants a challenge they can try find why programs die with sig11 in buildworld. (or why the system crashes in cd /usr/src/share; make obj) (I'll find that one tomorrow, hopefully they are related) Next milestone: make it reliable like this milestones after next: separate allocation of all resources needed for threads. design of specification for what is the 'RIGHT' thing to do in various corner cases. e.g. what does ps(1) show on a threaded process. more interestingly: what does ddb 'ps' show, (and procfs/linprocfs) what happens when a threaded program has one thread call 'fork()'? exec()? exit()? responses to the above questions should be made to the arch list but forst you should look at the patches. and particularly, apply them to a coppy of the current tree and have a look at the changes in proc.h etc. etc. julian (aching fingers) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Copyright Contradiction in libalias
Andrew Kenneth Milton [EMAIL PROTECTED] wrote: Once it's in the Public Domain you have abandoned your claim to copyright. Actually, that is not possible, at least in some countries (including Germany, for example). If you're the author of some piece of software, you're the holder of the Urheberrecht (the rights that you have, being the author). You cannot get rid of your Copyright even if you wanted to. There is no notion of public domain in the law. Declaring the software to be public domain merely means that you attach a license to the effect that everyone can do anything with it without asking you, _but_ you are still the original author, with all associated rights that you have as such. Actually you don't even have to include a phrase like Copyright (C) 2001 by John Doe, because it's implied. Regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. All that we see or seem is just a dream within a dream (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Interrupt messages from usb0 on CURRENT
I just upgraded to the latest sources (two hours ago) on my VAIO laptop and I'm now getting dozens of messages: Aug 22 15:00:07 sidhe /boot/kernel/kernel: usb0: interrupt, but not for us Aug 22 15:00:51 sidhe last message repeated 8 times Aug 22 15:03:02 sidhe last message repeated 19 times Aug 22 15:12:59 sidhe last message repeated 92 times Any idea? I also got an error where pccardd tried to attach my pcmcia card two times and it hung there. -=-=- Aug 22 13:45:07 sidhe /boot/kernel/kernel: ata0: resetting devices .. done Aug 22 13:45:09 sidhe /boot/kernel/kernel: sio1 at port 0x2f8-0x2ff iomem 0xd4000-0xd4fff irq 11 slot 0 on pccard0 Aug 22 13:45:09 sidhe /boot/kernel/kernel: sio1: type 16550A Aug 22 13:45:09 sidhe pccardd[232]: sio1: TOSHIBA (SLIMV90) inserted. Aug 22 13:45:09 sidhe pccardd[232]: sio1: TOSHIBA (SLIMV90) removed. Aug 22 13:45:14 sidhe pccardd[232]: Card TOSHIBA(SLIMV90) [REV#1 0] [4T12900LXX] matched TOSHIBA (SLIMV90) [(null)] [(null)] Aug 22 13:45:19 sidhe /boot/kernel/kernel: sio3 at port 0x2e8-0x2ef iomem 0xd400 0-0xd4fff irq 11 slot 0 on pccard0 Aug 22 13:45:19 sidhe /boot/kernel/kernel: sio3: type 16550A Aug 22 13:45:19 sidhe /boot/kernel/kernel: pcic0: Interrupt already established, possible multiple attach bug. Aug 22 13:45:19 sidhe /boot/kernel/kernel: pcic0: Interrupt already established, possible multiple attach bug. Aug 22 13:45:19 sidhe /boot/kernel/kernel: sio3: could not activate interrupt -=-=- Complete dmesg follows. -=-=- Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #4: Wed Aug 22 12:25:59 CEST 2001 [EMAIL PROTECTED]:/src/src/sys/i386/compile/nSIDHE Timecounter i8254 frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (364.74-MHz 686-class CPU) Origin = GenuineIntel Id = 0x66a Stepping = 10 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV, PAT,PSE36,MMX,FXSR real memory = 201261056 (196544K bytes) avail memory = 192356352 (187848K bytes) Preloaded elf kernel kernel at 0xc0351000. Preloaded elf module vesa.ko at 0xc035109c. Preloaded elf module if_ppp.ko at 0xc0351138. Preloaded elf module ums.ko at 0xc03511d8. Preloaded elf module random.ko at 0xc0351274. Pentium Pro MTRR support enabled VESA: v2.0, 2496k memory, flags:0x0, mode table:0xc03203a2 (122) VESA: MagicGraph 256 AV 48K Using $PIR table, 7 entries at 0xc00fdf50 apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: math processor on motherboard npx0: INT 16 interface pcib0:Intel 82443BX host to PCI bridge (AGP disabled) at pcibus 0 on motherboard pci0: PCI bus on pcib0 pci0: network, ethernet at 6.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xfc90-0xfc9f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0:Intel 82371AB/EB (PIIX4) USB controller port 0xfca0-0xfcbf irq 9 at dev ice 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: bridge, PCI-unknown at 7.3 (no driver attached) pci0: display, VGA at 8.0 (no driver attached) pci0: multimedia, audio at 8.1 (no driver attached) pci0: serial bus, FireWire at 9.0 (no driver attached) pci_cfgintr_unique: hard-routed to irq 9 pci_cfgintr: 0:10 INTA routed to irq 9 pcic0: Ricoh RL5C475 PCI-CardBus Bridge irq 9 at device 10.0 on pci0 pcic0: PCI Memory allocated: 0x4400 pccard0: PC Card bus (classic) on pcic0 pci0: simple comms at 11.0 (no driver attached) orm0: Option ROMs at iomem 0xc-0xcbfff,0xdc000-0xd on isa0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model GlidePoint, device ID 0 pmtimer0 on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio2 at port 0x3e8-0x3ef irq 5 on isa0 sio2: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0c02 can't assign resources unknown: PNP0303 can't assign resources unknown: PNP0501 can't assign resources unknown: SMCf010 can't assign resources unknown: PNP0f13 can't assign resources IPsec: Initialized Security Association Processing. IP Filter: v3.4.20 initialized. Default = pass all, Logging = enabled ad0: 6194MB TOSHIBA MK6412MAT [13424/15/63] at ata0-master UDMA33 Mounting root from ufs:/dev/ad0s1a linprocfs registered -=-=- -- Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- [EMAIL PROTECTED] FreeBSD caerdonn.eurocontrol.fr 5.0-CURRENT #46: Wed Jan 3 15:52:00 CET 2001 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current
non-present sched_yield
I have message kernel: cmd soffice.bin pid 4690 tried to use non-present sched_yield in logs triing to run staroffice on -CURRENT. But staroffice run fine, what about plans on implementing sched_yield() in kernel trhreads ? # uname -r 5.0-CURRENT # Aug 22 17:30:03 vbook /boot/kernel/kernel: cmd soffice.bin pid 4690 tried to use non-present sched_yield Aug 22 17:30:34 vbook last message repeated 1975 times Aug 22 17:31:14 vbook last message repeated 2036 times -- TSB Russian Express, Moscow Vladimir B. Grebenschikov, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ACPI on Sony VAIO z505s on fresh -CURRENT
Hi
Anybody tried subj ?
It compiles in, and seems to work:
Aug 17 14:16:58 vbook /boot/kernel/kernel: ACPI debug layer 0x0 debug level 0x0
Aug 17 14:16:59 vbook /boot/kernel/kernel: acpi0: PTLTDRSDT on motherboard
Aug 17 14:16:59 vbook /boot/kernel/kernel: acpi0: power button is handled as a fixed
feature programming model.
Aug 17 14:16:59 vbook /boot/kernel/kernel: Timecounter ACPI frequency 3579545 Hz
Aug 17 14:16:59 vbook /boot/kernel/kernel: acpi_cpu0: CPU on acpi0
Aug 17 14:16:59 vbook /boot/kernel/kernel: acpi_tz0: thermal zone on acpi0
Aug 17 14:16:59 vbook /boot/kernel/kernel: acpi_button0: Power Button on acpi0
Aug 17 14:16:59 vbook /boot/kernel/kernel: acpi_pcib0: Host-PCI bridge on acpi0
Aug 17 14:16:59 vbook /boot/kernel/kernel: pci0: PCI bus on acpi_pcib0
Aug 17 14:17:00 vbook /boot/kernel/kernel: acpi_pcib0: matched entry for 0.10.INTA
(source \_SB_.LNKB)
Aug 17 14:17:00 vbook /boot/kernel/kernel: acpi_pcib0: device is routed to IRQ 9
Aug 17 14:17:00 vbook /boot/kernel/kernel: acpi_cmbat0: Control method Battery on
acpi0
Aug 17 14:17:00 vbook /boot/kernel/kernel: acpi_acad0: AC adapter on acpi0
Aug 17 14:17:00 vbook /boot/kernel/kernel: acpi_timer0: 24-bit timer at 3.579545MHz
port 0x8008-0x800b on acpi0
Aug 17 14:17:01 vbook /boot/kernel/kernel: acpi_cpu0: set speed to 100.0%
Aug 17 14:17:01 vbook /boot/kernel/kernel: acpi_cpu: CPU throttling enabled, 8 steps
from 100% to 12.5%
acpidump - dumps a lot of information
But there are some problems with using acpi:
1st: it seems that acpi not emulates apm interface (/dev/{apm,apmctl}) so
apm-based utilites don't work (apmd, zzz, monitors and so)
Is it planned to have apm interface through acpi or not ?
If I compile both in kernel - apm code not works.
2nd: Where I can get more info about acpimodes, from man acpiconf(8):
-s type
Enters the specified sleep mode. Recognized types are 1, 2, 3,
4, and 5.
in man acpiconf(8) there are no mention about mode 4b
I have tried some:
1,2 - do nothing
5 - turn off machine without proper shutdown
3rd: I have tried couple utilites from http://people.freebsd.org/~jhb/acpi/
batt.c- works after patching, but if no battary present on laptop
shows 1 battary with unrealistic numbers
health.c - I can't make it work - it seems it lacks of defines in kernel
May be there are some other utilites for acpi ?
--
TSB Russian Express, Moscow
Vladimir B. Grebenschikov, [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Interrupt messages from usb0 on CURRENT
Ollivier Robert writes: I just upgraded to the latest sources (two hours ago) on my VAIO laptop and I'm now getting dozens of messages: Aug 22 15:00:07 sidhe /boot/kernel/kernel: usb0: interrupt, but not for us Aug 22 15:00:51 sidhe last message repeated 8 times Aug 22 15:03:02 sidhe last message repeated 19 times Aug 22 15:12:59 sidhe last message repeated 92 times Have same problem on VAIO, on fresh sources. Any idea? I also got an error where pccardd tried to attach my pcmcia card two times -- TSB Russian Express, Moscow Vladimir B. Grebenschikov, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Ringtones and Logos
Title: newlogo Personalise You Nokia with these great Logos!!! Bitch 21692 Hope 21716 Sex Bomb 21740 Dragon 1 20110 Love Beer 20203 fcuk 21951 Loving Eyes 20142 Trust No One 20409 Rizla 21256 The Simpsons 20399 Call Now ON "0906 400 2144" Quote the 5 digit number and your logo / Ringtone will be sent immediately!! For many more please visit www.mobiledirect.uk.com Get Your Mobile Rocking with these great Ringtones!!! Description Code Listen Baha Men - Who let the dogs out 10138 Bob the Builder - Can We Fix It? 11107 Shaggy Feat Rikrok - It Wasn't Me 11762 The Simpsons 10009 James Bond Theme 1 Star Wars Imperial March 10085 Please note: the call costs 1.50 per minute and the average call length is 2 minutes. Please ask bill payer for permission. Calls from mobiles cost more depending on service. The following phones receive both logos and tones - Nokia 3210, 3310,6090, 6110, 6130, 6150, 6210, 6250, 7110, 8110i, 8210, 8810, 8850, 9000i and 9110. Nokia models: 402 and 51XX receive logos only. Motorola T250, T2288, V50, V100, V2288, V8088 receive ring tones only. Please make sure that your mobile is listed here before ordering. Mobile Direct reserves the right not to refund your money if your phone is not listed here. If you experience any problem, call Customer Service on 0800 015 1175. Orders normally sent immediately, depending on network. For hundreds more ringtones and logos just click on to www.mobiledirect.uk.com - pass this on to a friend or stick it on the notice board Important Notice: If you do not wish to receive any more emails, please mail us on [EMAIL PROTECTED] and click "send." and your address will removed
Re: Copyright Contradiction in libalias
On Wed, 22 Aug 2001 20:04:46 +0400, Andrey A. Chernov [EMAIL PROTECTED] said: I mean common part of international copyright law. There is no such thing as ``international copyright law''. There is only national copyright law. Parties to the various international copyright conventions agree to harmonize their national law to meet a particular standard of protection, but I'm not aware of any case where such a convention was enacted directly into law. (In the case of the US, the Berne Convention was implemented as amendments to title 17 of the United States Code. US law provides for only a limited right of attribution, which does not apply to ``literary works''.) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI on Sony VAIO z505s on fresh -CURRENT
In message [EMAIL PROTECTED], Vladimir B. Grebensch
ikov $B$5$s$$$o$/(B:
acpidump - dumps a lot of information
But there are some problems with using acpi:
1st: it seems that acpi not emulates apm interface (/dev/{apm,apmctl}) so
apm-based utilites don't work (apmd, zzz, monitors and so)
Is it planned to have apm interface through acpi or not ?
If I compile both in kernel - apm code not works.
At least I don't have plan to imprement apmctl.There is more appropreate
way: kqueue. That is undergoing project. Imprementing ome apm-compatible
interface may be good thing.
2nd: Where I can get more info about acpimodes, from man acpiconf(8):
-s type
Enters the specified sleep mode. Recognized types are 1, 2, 3,
4, and 5.
in man acpiconf(8) there are no mention about mode 4b
I have tried some:
1,2 - do nothing
5 - turn off machine without proper shutdown
3rd: I have tried couple utilites from http://people.freebsd.org/~jhb/acpi/
batt.c- works after patching, but if no battary present on laptop
shows 1 battary with unrealistic numbers
health.c - I can't make it work - it seems it lacks of defines in kerne
l
health.c will not work because Thermal zone driver has no ioctl
interface for now.
But there is sysctl interface instead.
May be there are some other utilites for acpi ?
User interface of ACPI itself is not so fixed.
Takanori Watanabe
a href=http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html;
Public Key/a
Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Copyright Contradiction in libalias
On Wed, 22 Aug 2001 10:35:11 +0400, Andrey A. Chernov [EMAIL PROTECTED] said: No, author part of copyright can't be deattached, unless fraud happens. Only if you live in a country whose legal system recognizes ``moral rights''. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Copyright Contradiction in libalias
On Wed, Aug 22, 2001 at 11:48:52 -0400, Garrett Wollman wrote: On Wed, 22 Aug 2001 10:35:11 +0400, Andrey A. Chernov [EMAIL PROTECTED] said: No, author part of copyright can't be deattached, unless fraud happens. Only if you live in a country whose legal system recognizes ``moral rights''. I mean common part of international copyright law. F.e. Shakespeare works are in Public Domain (so Gutenberg project is able to publish them), but you can't claim you are the author of them. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
(Apparently) SOLVED: Re: QT23 not building
++ 21/08/01 02:21 +0200 - Salvo Bartolotta: || I am using XFree4 and my /etc/make.conf contains the required XFree86 || version string. || || opengl/qgl.h:63: GL/gl.h: No such file or directory || opengl/qgl.h:64: GL/glu.h: No such file or directory | These are included in || the Mesa port, and the qt23 port has a depend for | Mesa (USE_MESA= yes), but this is broken for XFree86 4. See my PR at At least, under -CURRENT. On (yet) another slice of mine -- featuring FreeBSD 4-S --, I can see the problematic files in place. | http://www.freebsd.org/cgi/query-pr.cgi?pr=29546, I'm still waiting for | someone on portmgr@ to commit it. BTW, I tried your suggestion, but it did NOT work: the same error occurred at the same place. getting lazy... OTOH, since qt had complained about missing files... I built Mesa3 and put those missing files, ie gl.h, glext.h, glu.h, and glx.h in /usr/X11R6/include/GL. Needless to say, qt-2.3.1 built without further complaints. So, rather than delve into the makefiles, I cheated square and fair :-) -- Salvo To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Interrupt messages from usb0 on CURRENT
Vladimir B. Grebenschikov wrote: Ollivier Robert writes: I just upgraded to the latest sources (two hours ago) on my VAIO laptop an d I'm now getting dozens of messages: Aug 22 15:00:07 sidhe /boot/kernel/kernel: usb0: interrupt, but not for us Aug 22 15:00:51 sidhe last message repeated 8 times Aug 22 15:03:02 sidhe last message repeated 19 times Aug 22 15:12:59 sidhe last message repeated 92 times Have same problem on VAIO, on fresh sources. Yes, back out the last change to dev/usb/uhci.c and dev/usb/ohci.c. Nick's commit is 100% bogus. It is a fundamental nature of PCI shared interrupts that all possible sources have to be polled. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Interrupt messages from usb0 on CURRENT
Same thing here, started with the build this morning... I know of one change that had been done in the past 36 hours to usb, but it should not have done this, as the patches I was using didn't produce this before the committer committed the patches. Maybe something else got changed as well? Vladimir B. Grebenschikov wrote: Ollivier Robert writes: I just upgraded to the latest sources (two hours ago) on my VAIO laptop and I'm now getting dozens of messages: Aug 22 15:00:07 sidhe /boot/kernel/kernel: usb0: interrupt, but not for us Aug 22 15:00:51 sidhe last message repeated 8 times Aug 22 15:03:02 sidhe last message repeated 19 times Aug 22 15:12:59 sidhe last message repeated 92 times Have same problem on VAIO, on fresh sources. Any idea? I also got an error where pccardd tried to attach my pcmcia card two times -- TSB Russian Express, Moscow Vladimir B. Grebenschikov, [EMAIL PROTECTED] jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Copyright Contradiction in libalias
From: Warner Losh [EMAIL PROTECTED] Subject: Re: Copyright Contradiction in libalias Date: Wed, Aug 22, 2001 at 12:24:56AM -0600 In message [EMAIL PROTECTED] Nate Williams writes: : : Once it's in the Public Domain you have abandoned your claim to copyright. : : On that released version, yes. But, not on subsuquent versions. I : still maintain my rights to do with the code as I please. Then you are creating a new work, based on the public domain work that went before it. Yes, and no. Distributing the exact same sources (with an extra copyright part) that says somebody should not copy and distribute it, as if it were in the public domain, a few weeks after is probably fraud. Arguments like but I put extra work in this second distribution, since I made this nifty packaging with bright colours and the CDROM contains those awesome .jpeg images of my new keyboard will probably sound a bit funny. The truth is that this is getting hairy. If you release something in the public domain, and then add value to it by changing a few things here and there, this is clearly a 'derivative' work. You do have the right to put any license you want on the derivative, of course - just like everyone else can put their own license on their own derivative works. So you are essentially very right ;-) -giorgos [ Isn't this thread by now more fit to -chat? ] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Copyright Contradiction in libalias
From: Crist J. Clark [EMAIL PROTECTED] Subject: Re: Copyright Contradiction in libalias Date: Tue, Aug 21, 2001 at 04:29:13PM -0700 On Tue, Aug 21, 2001 at 04:46:07PM -0600, Nate Williams wrote: However, I can't retroactively take away the rights of anyone who has gotten my 'public domain' software. You can't do anything. You have no more rights to the software than anyone else does (except the ability to say you wrote it). Even that (the ability to say you wrote it) might be difficult under certain circumstances. For instance, assuming that you release something to the public domain, and you suspect that someone's brand new and shining binary release of something that behaves like your own code is based on it, there is no clear way of determining whether the claim 'it was me who originally wrote this' is true or false. The recent thread about networking code in Windows and BSD implementation of the IP family of protocols is a good example of such a case :) Back to the original question, Charles Mott is the original author of said code, and he can release his software under any license he so pleases. So can FreeBSD with or without his consent since it is public domain software. Yep. True. The only problem is that if Charles Mott makes changes at a later date to his codebase, changes cannot be merged to the FreeBSD version without permission from him, even if the patches apply cleanly and break nothing that FreeBSD uses. Any future changes that Charles Mott makes to versions that are not explicitly declared by him to be public domain software, have to be rewritten from scratch by FreeBSD folk. -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Copyright Contradiction in libalias
:Yes, and no. Distributing the exact same sources (with an extra :copyright part) that says somebody should not copy and distribute it, :as if it were in the public domain, a few weeks after is probably :fraud. Arguments like but I put extra work in this second :distribution, since I made this nifty packaging with bright colours :and the CDROM contains those awesome .jpeg images of my new keyboard :will probably sound a bit funny. : :The truth is that this is getting hairy. If you release something in :the public domain, and then add value to it by changing a few things :here and there, this is clearly a 'derivative' work. You do have the :right to put any license you want on the derivative, of course - just :like everyone else can put their own license on their own derivative :works. : :So you are essentially very right ;-) : :-giorgos If you think it's that simple, read this: http://www.nyls.edu/samuels/copyright/beyond/articles/public.html I'll include some excerpts here. Basically, though, I agree with the author of this paper that if there is *confusion*, such as there being a copyright notice AND a notice of the work being in the public domain, and the PD notice does not specifically reference the copyright, then the law will be in favor of the work still being copyrighten. -Matt BEGIN However, such an analogy overlooks the special place that copyright law has held among all forms of property law. Clearly, the American trend in the recent statutes has been ever greater protection of authors against forfeiture of copyright, and almost a paternalistic attitude to protect authors against even voluntary acts that might transfer the copyright to another. [FN105] Such unique sensitivity to the rights of authors, and the protection against transfers, even fairly compensated, should caution against too liberal an interpretation of abandonment. Under section 204, a transfer of ownership of copyright is not valid unless an instrument of conveyance . . . is in writing and signed by the owner of the rights conveyed. If this statute of frauds prevents a verbal assignment of a copyright, even for consideration, [FN106] then the much more severe relinquishment of copyright to the public at large--probably without consideration--should require no less than such a writing. [FN107] END To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Copyright Contradiction in libalias (Summary)
I guess we can summarize now? :-) 1) If you are the author of software, it's a bad idea to simply release code into the Public Domain, mainly because you can't protect your self from litigation by placing disclaimers in your code. 2) Public Domain means you relinquish your copyright control over your work (but, you can still claim to be the author). Regaining control could be difficult, you can't simply take something and license it if it's not different enough. E.g. adding comments or a license isn't changing the work enough to give you or anyone else copyright control. The amount of difference required could come down to local law interpretations. 3) Actually abandoning copyright can be difficult. Some countries don't allow or recognise Public Domain. 4) Some countries require registration for copyright to be granted, others don't, some do both. 5) Some people incorrectly think that Public Domain is synonymous with OpenSource or Shareware. 6) Source Licenses are a way to remove or loosen restrictions already implicitly granted because of copyright laws. 7) Some countries don't have copyright laws so 1-6 are moot points in those countries anyway. 8) Noone contributing to this thread is a copyright lawyer. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: syscons VTY switch panic...
This seems to solve the problem. Thank you. How soon before VESA will be stable? I do prefer a 132x60 text-mode console... Kazutaka YOKOTA wrote: Would you please remove the vesa driver from the kernel and do not try loading the vesa module either, and see if things work? Actually, I have tried to get the VESA splash thing going, but never can get a nything to display... I can try removing that... I believe it is still set up this way... What are the limitations on image size and color-depth for the boot splash thi ng? The image must have 256 colors. Its size must be 1024x768 or smaller. If you don't have the vesa support in the kernel, the maximum size is 320x200. Kazu Kazutaka YOKOTA wrote: Do you by any chance use a VESA mode in text vtys? The vesa module in -CURRENT has problems now. If you try to set the VESA_800x600 mode in syscons, you will likely to hang your machine. This is a known problem, and is somewhat related to vm86 and context switching. I am afraid there is no immediate fix for it. Kazu I am getting this with regularity now. The one time I was available to see the panic, I forgot to go into the debug ge r and do a traceback, but it had something to do with a mwrite, and had a line concerning [maybe a buffer is?]... I know this isn't much to go on, but that's what I have. I'll get more info w hen I feel like wasting ten or fifteen minutes for a double-reboot... [is it necessary to do the `shutdown -r now` to write a ne w entropy, or can we just keep going if it boots without the proper entropy?]... I have pretty much isolated this to VTY switching via syscons. Occasionally , it will leave the system speaker in a constant tone until it reboots. This is very noticable then X exits. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put new bus_dmamap_load_mbuf() code
Maybe, but bus_dmamap_load() only lets you map one buffer at a time. I want to map a bunch of little buffers, and the API doesn't let me do that. And I don't want to change the API, because that would mean modifying busdma_machdep.c on each platform, which is a hell that I would rather avoid. bus_dmamap_load() is only one part of the API. bus_dmamap_load_mbuf or bus_dmamap_load_uio or also part of the API. They just don't happen to be impmeneted yet. 8-) Perhaps there should be an MD primitive that knows how to append to a mapping? This would allow you to write an MI loop that does exactly what you want. Any one of those ideas would be just fine. I eagerly await their realization. :) It's a separate list. The driver is reponsible for allocating the head of the list, then it hands it to bus_dmamap_list_alloc() along with the required dma tag. bus_dmamap_list_alloc() then calls bus_dmapap_create() to populate the list. The driver doesn't have to manipulate the list itself, until time comes to destroy it. Okay, but does this mean that bus_dmamap_load_mbuf no longer takes a dmamap? Drivers may want to allocate/manage the dmamaps in a different way. Yes, bus_dmamap_load_mbuf() accepts a dma tag, the head of the dmamap list, an mbuf, an segment array and a segment count. The Driver allocates the segment array with a certain number of members. It passes the array and segment count to bus_dmamap_load_mbuf(), which treats the segment count as the maximum number of segments that it can return to the caller. Once all the mappings have been done, it updates the segment count to indicate how many segments were actually needed. Then the driver transfers the info from the segment array into its DMA descriptor structures and kicks off the DMA operation. Once the device signals the transfer is done, the driver calls bus_dmamap_unload_mbuf() and bus_dmamap_destroy_mbuf() to unload the maps and return them to the map list for later use. It isn't until the driver calls bus_dmamap_list_destroy() that the dmamaps are actually released and the list free()ed. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = I like zees guys. Zey are fonny guys. Just keel one of zem. -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Interrupt messages from usb0 on CURRENT
In servalan.mailinglist.fbsd-current you write: I just upgraded to the latest sources (two hours ago) on my VAIO laptop and I'm now getting dozens of messages: Aug 22 15:00:07 sidhe /boot/kernel/kernel: usb0: interrupt, but not for us Aug 22 15:00:51 sidhe last message repeated 8 times Aug 22 15:03:02 sidhe last message repeated 19 times Aug 22 15:12:59 sidhe last message repeated 92 times This is apparently due to a change last night in the uhci and ohci drivers to report interrupts the USB code sees but which don't correspond to any actual USB activity. I saw the same thing last night after I upgraded (to try out jhb's latest fixes, which worked like a charm on the sound problem). I note that on my system the uhci0 and fxp0 are on the same IRQ: uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xef80-0xef9f irq 2 at device 7.2 on pci0 fxp0: Intel Pro 10/100B/100+ Ethernet port 0xef40-0xef5f mem 0xfea0-0xfeaf,0xfc4ff000-0xfc4f irq 2 at device 17.0 on pci0 I wonder if the interrupts not for us are actually interrupts from the Ethernet that the USB code sees because both the USB and the Ethernet are on the same irq. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
webdavfs correction
Seems like Apple has webdavfs for OS X... Any hope for a FreeBSD version? At least -- source? At least with an NDA, so binary modules can be made available for -stable and -current? Do our new Apple employees wield enough influence? -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Adaptec 7899 on-board controller and 4.4-RC
On Wed, Aug 22, 2001 at 07:02:54 +0200, Slawek Zak wrote: I have 2 such controlers in a Dell 6400. Both did work on 4.3-STABLE, updated about 4 weeks ago. After upgrade to 4.4-RC none of them is detected during boot. Did the ahc driver `suffer' some dramatic changes lately? There was some PCI breakage yesterday in -stable that should be fixed now. cvsup again and compile a new kernel. If it is still broken, send some more mail. :) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: webdavfs correction
so call me ignorant but what IS webdav? (or even dav) On Wed, 22 Aug 2001 [EMAIL PROTECTED] wrote: Seems like Apple has webdavfs for OS X... Any hope for a FreeBSD version? At least -- source? At least with an NDA, so binary modules can be made available for -stable and -current? Do our new Apple employees wield enough influence? -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Interrupt messages from usb0 on CURRENT
Richard Todd wrote: In servalan.mailinglist.fbsd-current you write: I just upgraded to the latest sources (two hours ago) on my VAIO laptop and I'm now getting dozens of messages: Aug 22 15:00:07 sidhe /boot/kernel/kernel: usb0: interrupt, but not for us Aug 22 15:00:51 sidhe last message repeated 8 times Aug 22 15:03:02 sidhe last message repeated 19 times Aug 22 15:12:59 sidhe last message repeated 92 times This is apparently due to a change last night in the uhci and ohci drivers to report interrupts the USB code sees but which don't correspond to any actual USB activity. I saw the same thing last night after I upgraded (to try out jhb's latest fixes, which worked like a charm on the sound problem). I note that on my system the uhci0 and fxp0 are on the same IRQ: uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xef80-0xef9f irq 2 at device 7.2 on pci0 fxp0: Intel Pro 10/100B/100+ Ethernet port 0xef40-0xef5f mem 0xfea0-0xf eaf,0xfc4ff000-0xfc4f irq 2 at device 17.0 on pci0 I wonder if the interrupts not for us are actually interrupts from the Ethernet that the USB code sees because both the USB and the Ethernet are on the same irq. Yes. Revert the last revision to uhci.c and/or ohci.c. usb was assuming it was the sole generator of those interrupts. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: webdavfs correction
On 22 Aug, Julian Elischer wrote:
so call me ignorant but what IS webdav? (or even dav)
On Wed, 22 Aug 2001 [EMAIL PROTECTED] wrote:
Seems like Apple has webdavfs for OS X... Any hope for a FreeBSD
version? At least -- source? At least with an NDA, so binary modules can
be made available for -stable and -current?
Do our new Apple employees wield enough influence?
From my earlier posting:
http://www.webdav.org/
/usr/ports/www/{neon,cadaver,sitecopy}/pkg-descr
See also:
http://www.xent.com/dec00/0391.html
Too bad, the published Apple's link
http://www.apple.com/macosx/usingosx/internet.html
is broken :(
-mi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
unproperly unmounted fs after apparently clean shutdown
hello, world\n I'm running FreeBSD 5.0-CURRENT #0: Mon Aug 6 23:23:45 CEST 2001. I turn on my box once a day when I come home and I recently noticed that about 1 out of 4 boots it tells me /boot/kernel/kernel: WARNING: / was not properly dismounted /boot/kernel/kernel: WARNING: /home was not properly dismounted /boot/kernel/kernel: WARNING: /opt was not properly dismounted /boot/kernel/kernel: WARNING: /usr was not properly dismounted /boot/kernel/kernel: /usr: lost blocks 6 files 5 /boot/kernel/kernel: WARNING: /usr/obj was not properly dismounted /boot/kernel/kernel: WARNING: /usr/ports/distfiles was not properly dismounted /boot/kernel/kernel: WARNING: /Var was not properly dismounted I'm positive that nothing unusual happened when I shut down the system with shutdown -h now, i.e. no some process would not die; ps axl advised or could not umount messages. I always wait for The operating system has halted. before turning power off. The list of file systems above is not complete; a df says Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/da2s1a127023479156894741%/ devfs 110 100%/dev /dev/da1s2f508143 322709 14478369%/home /dev/da0s1e59538393019 45473417%/opt /dev/da2s1f 3402629 2444357 68606278%/usr /dev/da1s4f 4030836 3548808 15956296%/usr/obj /dev/da1s2e 1984479 641906 118381535%/usr/ports/distfiles /dev/da2s1e508143 132454 33503828%/var /dev/da1s3g396895 114577 25056731%/Var /dev/da0s1d 1652219 1288389 23165385%/home/ncvs /dev/da2s53826552 164 203216444%/linux procfs 440 100%/proc /dev/md0 661344 6613440 100%/mnt/cd1 /dev/md1 620830 6208300 100%/mnt/cd2 /dev/md2 660102 6601020 100%/mnt/cd3 /dev/md3 649490 6494900 100%/mnt/cd4 This means that /var, /home/ncvs and /linux are umounted properly. Does anyone see similar behavior? Any clues? Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put new bus_dmamap_load_mbuf() code
My understanding is that you need a dmamap for every buffer that you want to map into bus space. You need one dmamap for each independantly manageable mapping. A single mapping may result in a long list of segments, regardless of whether you have a single KVA buffer or multiple KVA buffers that might contribute to the mapping. Yes yes, I understand that. But that's only if you want to map a buffer that's larger than PAGE_SIZE bytes, like, say, a 64K buffer being sent to a disk controller. What I want to make sure everyone understands here is that I'm not typically dealing with buffers this large: instead I have lots of small buffers that are smaller than PAGE_SIZE bytes. A single mbuf alone is only 256 bytes, of which only a fraction is used for data. An mbuf cluster buffer is usually only 2048 bytes. Transmitted packets are typically fragmented across 2 or 3 mbufs: the first mbuf contains the header, and the other two contain data. (Or the first one contains part of the header, the second one contains additional header data, and the third contains data -- whatever.) At most I will have 1500 bytes of data to send, which is less than PAGE_SIZE, and that 1500 bytes will be fragmented across a bunch of smaller buffers that are also smaller than PAGE_SIZE. Therefore I will not have one dmamap with multiple segments: I will have a bunch of dmamaps with one segment each. (I can hear somebody out there saying: What about jumbo frames? Yes, with jumbo frames, I will have 9K buffers to deal with, and in that case, you could have one dmamap with several segments, and I am taking this into account with the updated code I've written.) So unless I'm mistaken, for each mbuf in an mbuf list, what we have to do is this: - create a bus_dmamap_t for the data area in the mbuf using bus_dmamap_create() Creating a dmamap, depending on the architecture, could be expensive. You really want to create them in advance (or pool them), with at most one dmamap per concurrent transaction you support in your driver. The only problem here is that I can't really predict how many transactions will be going at one time. I will have at least RX_DMA_RING maps (one for each mbuf in the RX DMA ring), and some fraction of TX_DMA_RING maps. I could have the TX DMA ring completely filled with packets waiting to be DMA'ed and transmitted, or I may have only one entry in the ring currently in use. So I guess I have to allocate RX_DMA_RING + TX_DMA_RING dmamaps in order to be safe. - do the physical to bus mapping with bus_dmamap_load() bus_dmamap_load() only understands how to map a single buffer. You will have to pull pieces of bus_dmamap_load into a new function (or create inlines for common bits) to do this correctly. The algorithm goes something like this: foreach mbuf in the mbuf chain to load /* * Parse this contiguous piece of KVA into * its bus space regions. */ foreach bus space discontiguous region if (too_many_segs) return (error); Add new S/G element With the added complications of deferring the mapping if we're out of space, issuing the callback, etc. Why can't I just call bus_dmamap_load() multiple times, once for each mbuf in the mbuf list? (Note: for the record, an mbuf list usually contains one packet fragmented across multiple mbufs. An mbuf chain contains several mbuf lists, linked together via the m_nextpkt pointer in the header of the first mbuf in each list. By the time we get to the device driver, we always have mbuf lists only.) Chances are you are going to use the map again soon, so destroying it on every transaction is a waste. Ok, I spent some more time on this. I updated the code at: http://www.freebsd.org/~wpaul/busdma The changes are: - Tried to account for the case where an mbuf data region is larger than a page, i.e. when we have an mbuf with a 9K external buffer attached for use a jumbo ethernet frame. - Added routines to allocate a chunk of maps in a singly linked list, from which the other routines can grab them as needed. The driver attach routine calls bus_dmamap_list_init() with the max number of dmamaps that it will need, then the detach routine calls bus_dmamap_list_destroy() to nuke them when the driver is unloaded. The bus_dmamap_load_mbuf() routine uses the pre-allocated dmamaps from the list and bus_dmamap_list_destroy() returns them to the list when the transaction is completed. - Updated the modified if_sf driver to use the new code. Again, I've got this code running on the test box in the lab, so it's correct inasmuch as it compiles and runs, even though it may not be aesthetically pleasing. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu
Re: Where to put new bus_dmamap_load_mbuf() code
My understanding is that you need a dmamap for every buffer that you want to map into bus space. You need one dmamap for each independantly manageable mapping. A single mapping may result in a long list of segments, regardless of whether you have a single KVA buffer or multiple KVA buffers that might contribute to the mapping. Yes yes, I understand that. But that's only if you want to map a buffer that's larger than PAGE_SIZE bytes, like, say, a 64K buffer being sent to a disk controller. What I want to make sure everyone understands here is that I'm not typically dealing with buffers this large: instead I have lots of small buffers that are smaller than PAGE_SIZE bytes. A single mbuf alone is only 256 bytes, of which only a fraction is used for data. An mbuf cluster buffer is usually only 2048 bytes. Transmitted packets are typically fragmented across 2 or 3 mbufs: the first mbuf contains the header, and the other two contain data. (Or the first one contains part of the header, the second one contains additional header data, and the third contains data -- whatever.) At most I will have 1500 bytes of data to send, which is less than PAGE_SIZE, and that 1500 bytes will be fragmented across a bunch of smaller buffers that are also smaller than PAGE_SIZE. Therefore I will not have one dmamap with multiple segments: I will have a bunch of dmamaps with one segment each. The fact that the data is less than a page in size matters little to the bus dma concept. In other words, how is this packet presented to the hardware? Does it care that all of the component pieces are PAGE_SIZE in length? Probably not. It just wants the list of address/length pairs that compose that packet and there is no reason that each chunk needs to have it own, and potentially expensive, dmamap. Creating a dmamap, depending on the architecture, could be expensive. You really want to create them in advance (or pool them), with at most one dmamap per concurrent transaction you support in your driver. The only problem here is that I can't really predict how many transactions will be going at one time. I will have at least RX_DMA_RING maps (one for each mbuf in the RX DMA ring), and some fraction of TX_DMA_RING maps. I could have the TX DMA ring completely filled with packets waiting to be DMA'ed and transmitted, or I may have only one entry in the ring currently in use. So I guess I have to allocate RX_DMA_RING + TX_DMA_RING dmamaps in order to be safe. Yes or allocate them in chunks so that the total amount is only as large as the greatest demand your driver has ever seen. With the added complications of deferring the mapping if we're out of space, issuing the callback, etc. Why can't I just call bus_dmamap_load() multiple times, once for each mbuf in the mbuf list? Due to the cost of the dmamaps, the cost of which is platform and bus-dma implementation dependent - e.g. could be a 1-1 mapping to a hardware resource. Consider the case of having a full TX and RX ring in your driver. Instead of #TX*#RX dmamaps, you will now have three or more times that number. There is also the issue of coalessing the discontiguous chunks if there are too many chunks for your driver to handle. Bus dma is supposed to handle that for you (the x86 implementation doesn't yet, but it should) but it can't if it doesn't understand the segment limit per transaction. You've hidden that from bus dma by using a map per segment. (Note: for the record, an mbuf list usually contains one packet fragmented across multiple mbufs. An mbuf chain contains several mbuf lists, linked together via the m_nextpkt pointer in the header of the first mbuf in each list. By the time we get to the device driver, we always have mbuf lists only.) Okay, so I haven't written a network driver yet, but you got the idea, right? 8-) Chances are you are going to use the map again soon, so destroying it on every transaction is a waste. Ok, I spent some more time on this. I updated the code at: http://www.freebsd.org/~wpaul/busdma I'll take a look. The changes are: ... - Added routines to allocate a chunk of maps in a singly linked list, from which the other routines can grab them as needed. Are these hung off the dma tag or something? dmamaps may hold settings that are peculuar to the device that allocated them, so they cannot be shared with other clients of bus_dmamap_load_mbuf. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put new bus_dmamap_load_mbuf() code
The fact that the data is less than a page in size matters little to the bus dma concept. In other words, how is this packet presented to the hardware? Does it care that all of the component pieces are PAGE_SIZE in length? Probably not. It just wants the list of address/length pairs that compose that packet and there is no reason that each chunk needs to have it own, and potentially expensive, dmamap. Maybe, but bus_dmamap_load() only lets you map one buffer at a time. I want to map a bunch of little buffers, and the API doesn't let me do that. And I don't want to change the API, because that would mean modifying busdma_machdep.c on each platform, which is a hell that I would rather avoid. Why can't I just call bus_dmamap_load() multiple times, once for each mbuf in the mbuf list? Due to the cost of the dmamaps, the cost of which is platform and bus-dma implementation dependent - e.g. could be a 1-1 mapping to a hardware resource. Consider the case of having a full TX and RX ring in your driver. Instead of #TX*#RX dmamaps, you will now have three or more times that number. There is also the issue of coalessing the discontiguous chunks if there are too many chunks for your driver to handle. Bus dma is supposed to handle that for you (the x86 implementation doesn't yet, but it should) but it can't if it doesn't understand the segment limit per transaction. You've hidden that from bus dma by using a map per segment. Ok, a slightly different question: what happens if I call bus_dmamap_load() more than once with different buffers but with the same dmamap? (Note: for the record, an mbuf list usually contains one packet fragmented across multiple mbufs. An mbuf chain contains several mbuf lists, linked together via the m_nextpkt pointer in the header of the first mbuf in each list. By the time we get to the device driver, we always have mbuf lists only.) Okay, so I haven't written a network driver yet, but you got the idea, right? 8-) Just don't get 3c509 and 3c905 misxed up and we'll be fine. :) - Added routines to allocate a chunk of maps in a singly linked list, from which the other routines can grab them as needed. Are these hung off the dma tag or something? dmamaps may hold settings that are peculuar to the device that allocated them, so they cannot be shared with other clients of bus_dmamap_load_mbuf. It's a separate list. The driver is reponsible for allocating the head of the list, then it hands it to bus_dmamap_list_alloc() along with the required dma tag. bus_dmamap_list_alloc() then calls bus_dmapap_create() to populate the list. The driver doesn't have to manipulate the list itself, until time comes to destroy it. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = I like zees guys. Zey are fonny guys. Just keel one of zem. -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put new bus_dmamap_load_mbuf() code
The fact that the data is less than a page in size matters little to the bus dma concept. In other words, how is this packet presented to the hardware? Does it care that all of the component pieces are PAGE_SIZE in length? Probably not. It just wants the list of address/length pairs that compose that packet and there is no reason that each chunk needs to have it own, and potentially expensive, dmamap. Maybe, but bus_dmamap_load() only lets you map one buffer at a time. I want to map a bunch of little buffers, and the API doesn't let me do that. And I don't want to change the API, because that would mean modifying busdma_machdep.c on each platform, which is a hell that I would rather avoid. bus_dmamap_load() is only one part of the API. bus_dmamap_load_mbuf or bus_dmamap_load_uio or also part of the API. They just don't happen to be impmeneted yet. 8-) Perhaps there should be an MD primitive that knows how to append to a mapping? This would allow you to write an MI loop that does exactly what you want. there are too many chunks for your driver to handle. Bus dma is supposed to handle that for you (the x86 implementation doesn't yet, but it should) but it can't if it doesn't understand the segment limit per transaction. You've hidden that from bus dma by using a map per segment. Ok, a slightly different question: what happens if I call bus_dmamap_load() more than once with different buffers but with the same dmamap? The behavior is undefined. - Added routines to allocate a chunk of maps in a singly linked list, from which the other routines can grab them as needed. Are these hung off the dma tag or something? dmamaps may hold settings that are peculuar to the device that allocated them, so they cannot be shared with other clients of bus_dmamap_load_mbuf. It's a separate list. The driver is reponsible for allocating the head of the list, then it hands it to bus_dmamap_list_alloc() along with the required dma tag. bus_dmamap_list_alloc() then calls bus_dmapap_create() to populate the list. The driver doesn't have to manipulate the list itself, until time comes to destroy it. Okay, but does this mean that bus_dmamap_load_mbuf no longer takes a dmamap? Drivers may want to allocate/manage the dmamaps in a different way. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
