Re: fs/udf: vm pages overlap while reading large dir [patch]
on 26/02/2008 21:23 Pav Lucistnik said the following: Pav Lucistnik píše v út 05. 02. 2008 v 19:16 +0100: Andriy Gapon píše v út 05. 02. 2008 v 16:40 +0200: Yay, and can you fix the sequential read performance while you're at it? Kthx! this was almost trivial :-) See the attached patch, first hunk is just for consistency. The code was borrowed from cd9660, only field/variable names are adjusted. Just tested it with my shiny new Bluray drive, and it work wonders. Finally seamless playback of media files off UDF carrying media. So, how does it look WRT committing it? Pav, thank you for the feedback/reminder. In my personal option the latest patch posted and described at the following like is a very good candidate for commit: http://docs.FreeBSD.org/cgi/mid.cgi?47AA43B9.1040608 It might have a couple of style related issues, but it should improve things a bit even if some larger VM/VFS/GEOM issues remain. And by the way, a patch from the following PR would be a good side-dish for the above patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/78987 I think it is simple and obvious enough. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is it possible that modern wireless card only supports WPA and not WEP or this is a bug in the driver?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Yuri wrote: Isn't it better to have 2 separate flags in CAPS: for example WEP and WEPHW? WEP would mean that WEP is supported and WEPHW would mean that it's supported through hardware. It wouldn't make sense. Flags are used to specify capabilities of the interface, not things provided by the operating system. Yuri - -- Pietro Cerutti [EMAIL PROTECTED] PGP Public Key: http://gahr.ch/pgp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (FreeBSD) iEYEAREKAAYFAkfF81YACgkQwMJqmJVx946NRQCggHH4abFDjkRObQst1QgXm2Wb UlAAn2Y9B4u9v1o2FYg38txv8VlYjysF =10Nx -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fs/udf: vm pages overlap while reading large dir [patch]
Andriy Gapon píše v čt 28. 02. 2008 v 10:33 +0200: And while I have your attention, I have a related question. I have produced a bunch of ISO9660 Level 3 / UDF hybrid media with mkisofs, and when I mount the UDF part of them, the mount point (root directory of media) have 0x000 permissions. Yes that's right, d- in ls -l. That makes the whole volume inaccessible for everyone except root. Is this something you can mend in our UDF driver, or should I go dig inside mkisofs guts? Windows handle these media without any visible problems. -- Pav Lucistnik [EMAIL PROTECTED] [EMAIL PROTECTED] How will you recognize experienced hacker from beginner? Beginner thinks that kilobyte have 1000 bytes. Experienced hacker thinks one kilometer have 1024 meters. signature.asc Description: Toto je digitálně podepsaná část zprávy
pfind() in ithread handler
Hi, I'm trying to understand the cause of following panic. panic: Trying sleep, but thread marked as sleeping prohibited cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x17d sleepq_add() at sleepq_add+0x2e1 _sx_slock_hard() at _sx_slock_hard+0x15d _sx_slock() at _sx_slock+0xc1 pfind() at pfind+0x24 saa_intr() at saa_intr+0x313 ithread_loop() at ithread_loop+0xda fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xac3c0d30, rbp = 0 --- Can someone enlighten me on what is causing the panic and is it ok to use pfind() in interrupt handler (I have very limited understanding of kernel internals)? Code in question (taken from saa driver http://freebsd.ricin.com/ports/distfiles/kbtv-1.92.tbz) can be found at http://www.pastebin.ca/921830 TIA, Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fs/udf: vm pages overlap while reading large dir [patch]
on 28/02/2008 11:59 Pav Lucistnik said the following: Andriy Gapon píše v čt 28. 02. 2008 v 10:33 +0200: And while I have your attention, I have a related question. I have produced a bunch of ISO9660 Level 3 / UDF hybrid media with mkisofs, and when I mount the UDF part of them, the mount point (root directory of media) have 0x000 permissions. Yes that's right, d- in ls -l. That makes the whole volume inaccessible for everyone except root. Is this something you can mend in our UDF driver, or should I go dig inside mkisofs guts? Windows handle these media without any visible problems. I think this ought to be something in mkisofs, last I checked our code was fully conforming to the specs in this regard. And obviously it works with windoz, because it simply ignores the permissions :-) We might consider adding a fixup for such broken media (if my assessment is correct), but I'd rather prefer that it is fixed at the source. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pfind() in ithread handler
On 28/02/2008, Yuri Pankov [EMAIL PROTECTED] wrote: Hi, I'm trying to understand the cause of following panic. panic: Trying sleep, but thread marked as sleeping prohibited cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x17d sleepq_add() at sleepq_add+0x2e1 _sx_slock_hard() at _sx_slock_hard+0x15d _sx_slock() at _sx_slock+0xc1 pfind() at pfind+0x24 saa_intr() at saa_intr+0x313 ithread_loop() at ithread_loop+0xda fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xac3c0d30, rbp = 0 --- Can someone enlighten me on what is causing the panic and is it ok to use pfind() in interrupt handler (I have very limited understanding of kernel internals)? Code in question (taken from saa driver http://freebsd.ricin.com/ports/distfiles/kbtv-1.92.tbz) can be found at http://www.pastebin.ca/921830 TIA, Yuri You cannot sleep in high priority ithread handler, pfind() uses sleepable sx(9) lock. In your case it fail to acquire a shared lock and trying to sleep. Probably you should call pfind() elsewhere. wbr, pluknet ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs tag renaming after repo copy
Simon L. Nielsen [EMAIL PROTECTED] writes: John Polstra has made a script (Fixtags) for it which we use for the FreeBSD repository. I don't think he has any problems with it being distributed, but as it doesn't have a copyright statement i just want to ask before I distribute it... Uh... I wrote a replacement for that in 2001 (~des/bin/fixtags.pl). I'm surprised you still use John's version, which is excruciatingly slow, since 1) it's a shell script, 2) it's a *recursive* shell script, 3) it runs rcs twice for every modified tag. My version was under 3-clause BSD; I just switched it to 2-clause. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Modular type GENERIC?
On Thursday 28 February 2008, Adrian Chadd wrote: On 28/02/2008, David O'Brien [EMAIL PROTECTED] wrote: On Thu, Feb 28, 2008 at 03:26:55PM +0900, Adrian Chadd wrote: Is there some sane-ish way of auto-generating a list of modules given a config file? The device statements don't match up with the module name in all bar 4 or 5 places. Is there some chain of files I can munge to match things up? Not that I know of. :-( Crap. I may have to hand-massage something together just for testing then. Adrian How about: cd /boot/kernel; ls *.ko | sed 's/\.ko/_load=YES/' I think you still want to remove some modules by hand, for example snd_driver. -- Pieter de Goeje ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pfind() in ithread handler
2008/2/28, Yuri Pankov [EMAIL PROTECTED]: Hi, I'm trying to understand the cause of following panic. panic: Trying sleep, but thread marked as sleeping prohibited cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x17d sleepq_add() at sleepq_add+0x2e1 _sx_slock_hard() at _sx_slock_hard+0x15d _sx_slock() at _sx_slock+0xc1 pfind() at pfind+0x24 saa_intr() at saa_intr+0x313 ithread_loop() at ithread_loop+0xda fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xac3c0d30, rbp = 0 --- Can someone enlighten me on what is causing the panic and is it ok to use pfind() in interrupt handler (I have very limited understanding of kernel internals)? Code in question (taken from saa driver http://freebsd.ricin.com/ports/distfiles/kbtv-1.92.tbz) can be found at http://www.pastebin.ca/921830 ithreads cannot perform unbound sleeps and pfind() needs to access to allproc_lock which is a sx lock and *performs* an unbound sleep, so there is a mismatch. Btw, it sounds like allproc_lock and other similar locks are just using an sx lock for *legacy*, they should be probabilly converted to rwlock. It also imposes little problems in the TTY layer, for example, where I saw you need to use a unbounded sleeping primitive because of processes locks acquisitions. A nice janitor task would be to convert these sx locks into rw and see what happens. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs tag renaming after repo copy
Dag-Erling Smørgrav wrote at 14:58 +0100 on Feb 28, 2008: Simon L. Nielsen [EMAIL PROTECTED] writes: John Polstra has made a script (Fixtags) for it which we use for the FreeBSD repository. I don't think he has any problems with it being distributed, but as it doesn't have a copyright statement i just want to ask before I distribute it... Uh... I wrote a replacement for that in 2001 (~des/bin/fixtags.pl). I'm surprised you still use John's version, which is excruciatingly slow, since 1) it's a shell script, 2) it's a *recursive* shell script, 3) it runs rcs twice for every modified tag. My version was under 3-clause BSD; I just switched it to 2-clause. Sounds nice. But for those of us aren't in the club and don't have a freefall account (or wherever home dirs reside these days) ... ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs tag renaming after repo copy
John E Hein [EMAIL PROTECTED] writes: Dag-Erling Smørgrav wrote at 14:58 +0100 on Feb 28, 2008: Simon L. Nielsen [EMAIL PROTECTED] writes: John Polstra has made a script (Fixtags) for it which we use for the FreeBSD repository. I don't think he has any problems with it being distributed, but as it doesn't have a copyright statement i just want to ask before I distribute it... Uh... I wrote a replacement for that in 2001 (~des/bin/fixtags.pl). I'm surprised you still use John's version, which is excruciatingly slow, since 1) it's a shell script, 2) it's a *recursive* shell script, 3) it runs rcs twice for every modified tag. My version was under 3-clause BSD; I just switched it to 2-clause. Sounds nice. But for those of us aren't in the club and don't have a freefall account (or wherever home dirs reside these days) ... ? http://people.freebsd.org/~des/software/fixtags Unfortunately, Apache is set up in such a manner that I can't set the correct mime type (if I name it fixtags.pl, it thinks it's a CGI script and gives you a 403...) DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fs/udf: vm pages overlap while reading large dir [patch]
Pav Lucistnik wrote: Andriy Gapon píše v čt 28. 02. 2008 v 10:33 +0200: And while I have your attention, I have a related question. I have produced a bunch of ISO9660 Level 3 / UDF hybrid media with mkisofs, and when I mount the UDF part of them, the mount point (root directory of media) have 0x000 permissions. Yes that's right, d- in ls -l. That makes the whole volume inaccessible for everyone except root. Is this something you can mend in our UDF driver, or should I go dig inside mkisofs guts? Windows handle these media without any visible problems. I wonder if Windows even observes the permissions bits. You'd have to special-case the UDF driver code in FreeBSD, which certainly possible but not terribly attractive. I'd be interested to see what exactly mkiso is doing. Maybe it's putting permissions into extended attributes and assuming the filesystem driver will read those instead. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs tag renaming after repo copy
Dag-Erling Smørgrav wrote at 20:36 +0100 on Feb 28, 2008:
http://people.freebsd.org/~des/software/fixtags
Unfortunately, Apache is set up in such a manner that I can't set the
correct mime type (if I name it fixtags.pl, it thinks it's a CGI script
and gives you a 403...)
Thanks. I did something similar (not using cvs ops, but rather
directly munging the ,v file) with awk, but I had issues with binary
files. I also didn't have any fancy exclude/include feature (nice!) or
try to guess which tags are vendor tags (it looks like you're just
trying to match a '.' - why does that make it a vendor tag?).
Minor issue...
syntax error at /tmp/jhein/fixtags line 68, near
syntax error at /tmp/jhein/fixtags line 68, near @exclude)
syntax error at /tmp/jhein/fixtags line 69, near @include)
syntax error at /tmp/jhein/fixtags line 74, near } else
--- fixtags.orig2008-02-28 13:11:33.0 -0700
+++ fixtags 2008-02-28 13:10:16.0 -0700
@@ -64,7 +64,7 @@
} elsif ($phase == 2) {
if (m/^\t([^:]+):([0-9.]+);?\s*$/) {
$tag = $1;
- if ($tag !~ m/\./ # skip vendor tags
+ if ($tag !~ m/\./ # skip vendor tags
([EMAIL PROTECTED] || !grep({ $_ eq $tag } @exclude))
([EMAIL PROTECTED] || grep({ $_ eq $tag } @include))) {
print($tag - old_$tag\n)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fs/udf: vm pages overlap while reading large dir [patch]
Andriy Gapon wrote: on 26/02/2008 21:23 Pav Lucistnik said the following: Pav Lucistnik píše v út 05. 02. 2008 v 19:16 +0100: Andriy Gapon píše v út 05. 02. 2008 v 16:40 +0200: Yay, and can you fix the sequential read performance while you're at it? Kthx! this was almost trivial :-) See the attached patch, first hunk is just for consistency. The code was borrowed from cd9660, only field/variable names are adjusted. Just tested it with my shiny new Bluray drive, and it work wonders. Finally seamless playback of media files off UDF carrying media. So, how does it look WRT committing it? Pav, thank you for the feedback/reminder. In my personal option the latest patch posted and described at the following like is a very good candidate for commit: http://docs.FreeBSD.org/cgi/mid.cgi?47AA43B9.1040608 It might have a couple of style related issues, but it should improve things a bit even if some larger VM/VFS/GEOM issues remain. And by the way, a patch from the following PR would be a good side-dish for the above patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/78987 I think it is simple and obvious enough. I will commit both of these to CVS today. Thanks again. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
PXE on 7.0 problem and solution
Hi there, Installing 7.0 via PXE has a slight problem that is easily worked around. The file /boot/mfsroot.gz on the installation media needs to be unzipped to make PXE boot via tftp/nfs work. Otherwise the loader ultimately complains that it cant find the device to boot from. For example, if you have the installation media living at /usr/pxe/nfs/ on the PXE server, then do: gzip -d /usr/pxe/nfs/boot/mfsroot.gz After doing this it now loads the kernel and starts the installation procedure as expected. Someone more knowledgeable than me might want to let whoever needs to know about this. Apart from that, it looks great, the work is appreciated, thanks for the new release :-) Cheers, Tim. We are BSD ... resistance is futile. http://www.freebsd.org/ - http://www.openbsd.org/ - http://www.netbsd.org/ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs tag renaming after repo copy
John E Hein wrote at 13:20 -0700 on Feb 28, 2008: Thanks. I did something similar (not using cvs ops, but rather directly munging the ,v file) with awk, but I had issues with binary files. Regarding binary files, I tried my awk again, but this time with gawk, and it had no problems. I wonder if I stumbled onto a one-true-awk issue (or if my expectations were wrong). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PXE on 7.0 problem and solution
Tim Clewlow wrote: Hi there, Installing 7.0 via PXE has a slight problem that is easily worked around. The file /boot/mfsroot.gz on the installation media needs to be unzipped to make PXE boot via tftp/nfs work. Otherwise the loader ultimately complains that it cant find the device to boot from. For example, if you have the installation media living at /usr/pxe/nfs/ on the PXE server, then do: gzip -d /usr/pxe/nfs/boot/mfsroot.gz After doing this it now loads the kernel and starts the installation procedure as expected. Someone more knowledgeable than me might want to let whoever needs to know about this. Apart from that, it looks great, the work is appreciated, thanks for the new release :-) I've had problems with other files fetched over NFS in the past. In theory (at least that's what a tcpdump says), it should be possible to provide all files gzipped, and even split the files in smaller chunks. Files are tried in this order: boot/loader.rc.split boot/loader.rc.gz.split boot/loader.rc.gz boot/loader.rc However, I only got the plain files to work reliably. Erik ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
problem with ldconfig
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I had a problem with my raid array, and during a fix, I noticed that a thing I'd gotten very used to during my time running Linux was a really bad thing for FreeBSD (the usage of a /boot partition for booting only, to store the kernel, but nothing else). Well, after I had reloaded my raid, and fixed the /boot to be one nice big parition, I have a several very weird things that have cropped up. First one, I'd kept a 100G IDE disk hanging around just in case I hadn't installed the raid right, so I could use it for backup, and this saved me, but now, it no longer boots right. I used to either hit F1 (to boot the 100G IDE, called ad1, ad0 being a cdrom), or I would hit F5 then F1, to boot from the raid, called da0. Well, now, no matter what Function key I hit, it boots from ad1 regardless, and the only way I can boot the raid is the use the #6 option of the beastie menu (to catch the ld cli) and set currdev to disk2s1a, unload, load, then boot. This works fine, but howcome I can't just get it to boot without all this intervention? I have already tried reloading the boot manager into both ad1s1 and da0s1, no change. Well, the other thing that's come up, I can't get my nvidia driver to work along with xorg. It used to show it's arrival both in kldstat, AND also because, in /dev, a file named nvidiactl would show up. This has stopped happening. I had been using the old version 100.14.19, and when I checked the nvidia website, it seems a couple of newer versions had appeared, so I downloaded and built version 169.12. Don't ask me why the crazy version numbering, I looked around for something like a changelog, but had no luck. Anyhow, updating to the newer version wasn't too hard, but didn't show any change. Consulting the /var/log/Xorg.0.log file, even though kldstat says that nvidia.ko is loaded, it never shows a /dev/nvidiactl, and the log file says clearly that it never finds the Nvidia kernel module. Using it with Vesa lets me limp, so I do that, but howcome? OK, I'm not giving my ldconfig problem to you folks, its quite likely its a FreeBSD-current problem, so let those folks handle that one. Boy, I feel like the little boy who cried wolf! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHxylOz62J6PPcoOkRAudcAJ9ex65oZUoh+0gf/7WcpNi6KhwsxwCgje63 m4GwVJZrkoU3McfHK1NAArk= =wLpy -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
umass: should the device specific information be moved from C code to the text file?
Currently all devices supported by umass driver are listed in * sys/dev/usb/usbdevs - which has vendor table (vendor-id/name) - and product table (ref-to-vendor-id/product-id/name) and * sys/dev/usb/umass.c - which has some per-device flags. The problem with this way is that some people might want to disable umass for particular devices. For example some people prefer to use gphoto2 with usb-cameras and gphoto2 needs the device to be ugen. I suggest device specific information should be moved from sys/dev/usb/usbdevs and sys/dev/usb/umass.c to some text file (ex. /etc/umass-devices) which would be read by umass driver when it's loaded. This way users will be able to easily remove/add entries without the need to recompile the module. Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs tag renaming after repo copy
On 2008.02.28 14:58:53 +0100, Dag-Erling Smørgrav wrote: Simon L. Nielsen [EMAIL PROTECTED] writes: John Polstra has made a script (Fixtags) for it which we use for the FreeBSD repository. I don't think he has any problems with it being distributed, but as it doesn't have a copyright statement i just want to ask before I distribute it... Uh... I wrote a replacement for that in 2001 (~des/bin/fixtags.pl). I'm surprised you still use John's version, which is excruciatingly slow, since 1) it's a shell script, 2) it's a *recursive* shell script, 3) it runs rcs twice for every modified tag. If it ain't borken :-). Speed is rarely an issue since the CVS master server is fast, and most of the time only a few files are copied. For other intersted parties I got OK from John Polstra to put his script online with std. BSD license so it can now be found at http://people.freebsd.org/~simon/scripts/Fixtags . In case anyone is interested I put the script I use for repo-copies at FreeBSD.org online as http://people.freebsd.org/~simon/scripts/cvs_repo_copy . The script probably need to be adjusted to local config and use at your own risk etc - but it hasn't done anything bad for me yet :-). -- Simon L. Nielsen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs tag renaming after repo copy
Simon L. Nielsen wrote: For other intersted parties I got OK from John Polstra to put his script online with std. BSD license so it can now be found at http://people.freebsd.org/~simon/scripts/Fixtags . In case anyone is interested I put the script I use for repo-copies at FreeBSD.org online as http://people.freebsd.org/~simon/scripts/cvs_repo_copy . The script probably need to be adjusted to local config and use at your own risk etc - but it hasn't done anything bad for me yet :-). Thanks for these. Any reason they couldn't be added to the repository in src/tools/tools/repocopy/ or similar so those who are interested don't have to worry about having a stale version in the future? -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Modular type GENERIC?
On 28/02/2008, Pieter de Goeje [EMAIL PROTECTED] wrote: cd /boot/kernel; ls *.ko | sed 's/\.ko/_load=YES/' I think you still want to remove some modules by hand, for example snd_driver. Yes, but I'm reasonably sure GENERIC doesn't include -everything-. In any case, simply doing that confused loader quite badly. It crashed after all the modules had been loaded. Adrian -- Adrian Chadd - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs tag renaming after repo copy
John E Hein [EMAIL PROTECTED] writes:
- if ($tag !~ m/\./ # skip vendor tags
+ if ($tag !~ m/\./ # skip vendor tags
([EMAIL PROTECTED] || !grep({ $_ eq $tag } @exclude))
([EMAIL PROTECTED] || grep({ $_ eq $tag } @include))) {
Oops... Maybe that's why people were still using John's version :)
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umass: should the device specific information be moved from C code to the text file?
On Thu, Feb 28, 2008 at 02:14:58PM -0800, Yuri wrote: Currently all devices supported by umass driver are listed in * sys/dev/usb/usbdevs - which has vendor table (vendor-id/name) - and product table (ref-to-vendor-id/product-id/name) and * sys/dev/usb/umass.c - which has some per-device flags. And (for completeness): * src/sys/cam/scsi/scsi_da.c - contains device quirks. I suggest device specific information should be moved from sys/dev/usb/usbdevs and sys/dev/usb/umass.c to some text file (ex. /etc/umass-devices) which would be read by umass driver when it's loaded. This sounds like a nice idea - it's also a nuisance having to recompile the kernel just to support a weird new USB device you've acquired. Unfortunately, accessing the filesystem from within the kernel is not that easy. One problem with your suggestion of accessing the file when umass is loaded is that if imass is compiled into the kernel, it will go through the probe/attach phase before there's a root filesystem - which makes reading files somewhat difficult. What might be more useful is for the USB system to interrogate a file (or similar) when a USB device is inserted to allow the user to control which usb driver gains control of the device - as well as the camera example you use, this would also be useful with multi-function printer/scanner/... devices. Again, accessing a file is not trivial but may be practical. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgputmyPBcgKI.pgp Description: PGP signature
