Re: New features for -current
Riccardo Torrini wrote: Over than an year ago (9.9.2000) I submitted a pr (kern/21154) to ask renaming from actual *_saver.ko to saver_*.ko of saver modules to uniform names under /boot/kernel as sound (snd_*), interfaces (if_*), splash (splash_*) and netgraph (ng_*). Thanks for the reminder, I just closed that PR. :) This change would cause a lot of uphevel, a lot of source duplication in the cvs repository, and wouldn't provide any clear benefit, other than making ls(1) a little more orderly in the modules directory. Things work fine the way they are, so changing this isn't worth what it would cost. Another question: I noticed good support for USB peripherals like scanner, mp3 player (rio) mouse and ethernet but nothing to use a photo camera (yes, I buy an inexpensive usb digital photo camera, Agfa ePhoto-CL18) and I try to compile gphoto because it recently added support for CL-18 (w/out success). Nothing gets done around here unless someone who cares does it... someone else already explained why doing this in userland would be a better way to handle it, good luck. :) -- We will not tire, we will not falter, and we will not fail. - George W. Bush, President of the United States September 20, 2001 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
New features for -current
Over than an year ago (9.9.2000) I submitted a pr (kern/21154)
to ask renaming from actual *_saver.ko to saver_*.ko of saver
modules to uniform names under /boot/kernel as sound (snd_*),
interfaces (if_*), splash (splash_*) and netgraph (ng_*).
I tryed to figure where are used and I found only /etc/rc.i386:
kldstat -v | grep -q _saver || kldload ${saver}_saver
need to be changed to:
kldstat -v | grep -q saver_ || kldload saver_${saver}
Is this really so stupid? I think order is important...
Another question: I noticed good support for USB peripherals
like scanner, mp3 player (rio) mouse and ethernet but nothing
to use a photo camera (yes, I buy an inexpensive usb digital
photo camera, Agfa ePhoto-CL18) and I try to compile gphoto
because it recently added support for CL-18 (w/out success).
Would be a great idea add /dev/uphoto and even better a sort
of photo-file-system, where read is mapped to download image,
unlink to delete and maybe create file to take a picture so
we can use ls, cp, rm and touch to access photo camera...
Riccardo.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: New features for -current
Riccardo Torrini [EMAIL PROTECTED] wrote: Would be a great idea add /dev/uphoto and even better a sort of photo-file-system, where read is mapped to download image, unlink to delete and maybe create file to take a picture so we can use ls, cp, rm and touch to access photo camera... Yes, great idea, Riccardo -- please do it. :-) However, there is no standard for accessing digital photo cameras via USB. Recently, some of them seem to comply with the mass storage protocol (BSD's umass driver), but the majority of them use proprietary protocols. Even the same vendor uses different protocols for different of his cameras. So, basically you would have to write a separate kernel driver for every camera. This isn't feasible. It is probably much better to handle these issues in userland code. As an example, you could have a look at the oPhoto tool which handles the Kodak DC240, DC280 and DC3400 under Free- BSD (and possibly also others, but _not_ the Kodak DC220, DC260 and DC265). These are all USB photo cameras. The tool is written in userland code and uses the generic ugen driver to access the camera, which works pretty well. If you absolutely want to access the images like a real filesystem (I don't think this would have any real advan- tage), you could wrap an NFS userland server around the code. Bloating the kernel with such stuff is a bad idea, IMO. Regards Oliver PS: oPhoto: http://www.fromme.com/ophoto/ -- 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
