Re: usb4bsd patch review
On Friday 22 August 2008, Alexander Leidinger wrote: Quoting Kris Kennaway [EMAIL PROTECTED] (from Fri, 22 Aug 2008 10:59:38 +0200): Alexander Leidinger wrote: Quoting M. Warner Losh [EMAIL PROTECTED] (from Thu, 21 Aug 2008 11:52:10 -0600 (MDT)): In message: [EMAIL PROTECTED] Kris Kennaway [EMAIL PROTECTED] writes: : Hans Petter Selasky wrote: : The USB stack will work fine without usbconfig. Its purpose is : mostly to : view the currently attached USB devices, where the USB devices : are located : and to select a non-default USB configuration. One thing which : might be missed is to change owner and permission of a USB device, which means you : must be either UID=root or GID=OPERATOR to be able to use USB : devices that : create devices under /dev/ . : : OK great, this isn't critical either. I think all of the issues I : raised are agreed upon now! Wait a moment. Does this mean the devfs stuff to handle the access rights (devfs.rules or manual chown/chmod by root) does not work with the new usb stuff? If the answer is yes, I would see this as some kind of nasty bug (I don't think this shall be a showstopper, as long as this is fixed later). Yes, he said it will be fixed later. You are aware that I point out that this may or may not suggest that HPS is circumventing the normal devfs infrastructure and that this may or may not be a problem and should be reviewed by someone with knowledge about the devfs infrastructure? And as he mentioned that in the context of the userland utilities, it may be interesting if this means if an USB specific userland utility will be responsible to change the ownership and file access or not. If yes, what are the consequences from a security point of view and what about POLA (devfs.rules, chown/chmod)? I want to see this new USB subsystem, but if the answer to the above paragraph is yes, then this would be a showstopper for me (IMO the replacement should work in this regard as before, I don't say it can not be changed after enough people agree that the replacement was successful). Bye, Alexander. Hi Alexander, You have to ask Paul Henning Kamp about that. He does not like the idea about /dev/ being the inventory list. Besides, there are no more visible /dev/ devices. All devices are so-called cloneable and invisible, so you need a separate utility. The good news is that you can set the permissions on a USB subtree (a HUB and all subdevices) before devices are eventually plugged ! --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb4bsd patch review
Quoting Hans Petter Selasky [EMAIL PROTECTED] (Sat, 23 Aug 2008 08:03:55 +0200): On Friday 22 August 2008, Alexander Leidinger wrote: Quoting Kris Kennaway [EMAIL PROTECTED] (from Fri, 22 Aug 2008 10:59:38 +0200): Alexander Leidinger wrote: Quoting M. Warner Losh [EMAIL PROTECTED] (from Thu, 21 Aug 2008 11:52:10 -0600 (MDT)): In message: [EMAIL PROTECTED] Kris Kennaway [EMAIL PROTECTED] writes: : Hans Petter Selasky wrote: : The USB stack will work fine without usbconfig. Its purpose is : mostly to : view the currently attached USB devices, where the USB devices : are located : and to select a non-default USB configuration. One thing which : might be missed is to change owner and permission of a USB device, which means you : must be either UID=root or GID=OPERATOR to be able to use USB : devices that : create devices under /dev/ . : : OK great, this isn't critical either. I think all of the issues I : raised are agreed upon now! Wait a moment. Does this mean the devfs stuff to handle the access rights (devfs.rules or manual chown/chmod by root) does not work with the new usb stuff? If the answer is yes, I would see this as some kind of nasty bug (I don't think this shall be a showstopper, as long as this is fixed later). Yes, he said it will be fixed later. You are aware that I point out that this may or may not suggest that HPS is circumventing the normal devfs infrastructure and that this may or may not be a problem and should be reviewed by someone with knowledge about the devfs infrastructure? And as he mentioned that in the context of the userland utilities, it may be interesting if this means if an USB specific userland utility will be responsible to change the ownership and file access or not. If yes, what are the consequences from a security point of view and what about POLA (devfs.rules, chown/chmod)? I want to see this new USB subsystem, but if the answer to the above paragraph is yes, then this would be a showstopper for me (IMO the replacement should work in this regard as before, I don't say it can not be changed after enough people agree that the replacement was successful). Bye, Alexander. Hi Alexander, You have to ask Paul Henning Kamp about that. He does not like the idea about /dev/ being the inventory list. We already have a lot of cloning devices, so it's not about showing a device node in /dev or not, I'm talking about chmod/chflags/devfs.rules. Besides, there are no more visible /dev/ devices. All devices are so-called cloneable and invisible, so you need a separate utility. The good news is No, devfs.rules is handling this case already, no need for another utility: ---snip--- NAME devfs.rules -- devfs configuration information DESCRIPTION The devfs.rules file provides an easy way to create and apply devfs(8) rules, even for devices that are not available at boot. For devices available at boot, see devfs.conf(5). ---snip--- With your new utility you are changing the security policy, and this without discussing this in public (who is able to change the permissions, are changes permanent and survive a reboot, ...). With devfs.rules we already have a tested and reviewed feature where root can configure access. that you can set the permissions on a USB subtree (a HUB and all subdevices) before devices are eventually plugged ! I don't know of a scenario where this is useful, but I'm not surprised if someone has an use for this. And I think this feature can be available while respecting the current semantics of devfs and devfs.rules (e.g. if your feature is used, give priority to it, else respect devfs.rules). Bye, Alexander. -- Ferengi Rule of Acquisition #7: Keep your ears open. -- ST:DS9, In the Hands of the Prophets http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb4bsd patch review
Hi, I've CC'ed PHK in case he has any comments on this issue. I think the solution is that you use devd.conf instead of devfs.conf to do this in the future. The problem about devfs.rules with regard to USB is that you don't know what you are giving permissions to. A rule that gives permission to /dev/ulpt0 will give permissions to the first printer you plug into the USB system. That is not neccessarily what the user wants. --HPS On Saturday 23 August 2008, Alexander Leidinger wrote: Quoting Hans Petter Selasky [EMAIL PROTECTED] (Sat, 23 Aug 2008 08:03:55 +0200): On Friday 22 August 2008, Alexander Leidinger wrote: Quoting Kris Kennaway [EMAIL PROTECTED] (from Fri, 22 Aug 2008 10:59:38 +0200): Alexander Leidinger wrote: Quoting M. Warner Losh [EMAIL PROTECTED] (from Thu, 21 Aug 2008 11:52:10 -0600 (MDT)): In message: [EMAIL PROTECTED] Kris Kennaway [EMAIL PROTECTED] writes: : Hans Petter Selasky wrote: : The USB stack will work fine without usbconfig. Its purpose is : mostly to : view the currently attached USB devices, where the USB devices : are located : and to select a non-default USB configuration. One thing which : might be missed is to change owner and permission of a USB : device, which means you : must be either UID=root or GID=OPERATOR to be able to use USB : devices that : create devices under /dev/ . : : OK great, this isn't critical either. I think all of the issues : I raised are agreed upon now! Wait a moment. Does this mean the devfs stuff to handle the access rights (devfs.rules or manual chown/chmod by root) does not work with the new usb stuff? If the answer is yes, I would see this as some kind of nasty bug (I don't think this shall be a showstopper, as long as this is fixed later). Yes, he said it will be fixed later. You are aware that I point out that this may or may not suggest that HPS is circumventing the normal devfs infrastructure and that this may or may not be a problem and should be reviewed by someone with knowledge about the devfs infrastructure? And as he mentioned that in the context of the userland utilities, it may be interesting if this means if an USB specific userland utility will be responsible to change the ownership and file access or not. If yes, what are the consequences from a security point of view and what about POLA (devfs.rules, chown/chmod)? I want to see this new USB subsystem, but if the answer to the above paragraph is yes, then this would be a showstopper for me (IMO the replacement should work in this regard as before, I don't say it can not be changed after enough people agree that the replacement was successful). Bye, Alexander. Hi Alexander, You have to ask Paul Henning Kamp about that. He does not like the idea about /dev/ being the inventory list. We already have a lot of cloning devices, so it's not about showing a device node in /dev or not, I'm talking about chmod/chflags/devfs.rules. Besides, there are no more visible /dev/ devices. All devices are so-called cloneable and invisible, so you need a separate utility. The good news is No, devfs.rules is handling this case already, no need for another utility: ---snip--- NAME devfs.rules -- devfs configuration information DESCRIPTION The devfs.rules file provides an easy way to create and apply devfs(8) rules, even for devices that are not available at boot. For devices available at boot, see devfs.conf(5). ---snip--- With your new utility you are changing the security policy, and this without discussing this in public (who is able to change the permissions, are changes permanent and survive a reboot, ...). With devfs.rules we already have a tested and reviewed feature where root can configure access. that you can set the permissions on a USB subtree (a HUB and all subdevices) before devices are eventually plugged ! I don't know of a scenario where this is useful, but I'm not surprised if someone has an use for this. And I think this feature can be available while respecting the current semantics of devfs and devfs.rules (e.g. if your feature is used, give priority to it, else respect devfs.rules). ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb4bsd patch review
In message [EMAIL PROTECTED], Hans Petter Selasky writes: The problem about devfs.rules with regard to USB is that you don't know what you are giving permissions to. A rule that gives permission to /dev/ulpt0 will give permissions to the first printer you plug into the USB system. That is not neccessarily what the user wants. I think this might be a good time to consider the devd/devfs distribution of work. The reason devfs(8) works like firewall rules is that we did not want some mandatory daemon to set the modes, in particular on embedded systems. The alternative solution is to always create device nodes root:wheel r-- and let the daemon set the mode as desired. This model has the advantage of not needing the uid, gid and mode arguments to make_dev, something that has always been acknowleded as a kludge. The down side is that devd(8) becomes a mandatory daemon on most systems. Given that devfs(8) has not exactly been a stellar success and that it often and repeatedly bites people with it slightly pedantic semantics, transitioning in that direction might be a good thing. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb4bsd patch review
In message: [EMAIL PROTECTED] Poul-Henning Kamp [EMAIL PROTECTED] writes: : In message [EMAIL PROTECTED], Hans Petter Selasky writes: : : : The problem about devfs.rules with regard to USB is that you don't know what : you are giving permissions to. A rule that gives permission to /dev/ulpt0 : will give permissions to the first printer you plug into the USB system. That : is not neccessarily what the user wants. : : I think this might be a good time to consider the devd/devfs : distribution of work. : : The reason devfs(8) works like firewall rules is that we did not want : some mandatory daemon to set the modes, in particular on embedded : systems. : : The alternative solution is to always create device nodes root:wheel r-- : and let the daemon set the mode as desired. : : This model has the advantage of not needing the uid, gid and mode arguments : to make_dev, something that has always been acknowleded as a kludge. : : The down side is that devd(8) becomes a mandatory daemon on most systems. : : Given that devfs(8) has not exactly been a stellar success and that it : often and repeatedly bites people with it slightly pedantic semantics, : transitioning in that direction might be a good thing. While this may be a good idea, I'm hesitant about races that it may introduce. This is the classic point of attack: do something between steps of a formerly atomic operation that was made non-atomic. I can't think of anything off the top of my head, but I'm still concerned. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb4bsd patch review
Quoting Poul-Henning Kamp [EMAIL PROTECTED] (Sat, 23 Aug 2008 15:27:24 +): In message [EMAIL PROTECTED], Hans Petter Selasky writes: The problem about devfs.rules with regard to USB is that you don't know what you are giving permissions to. A rule that gives permission to /dev/ulpt0 will give permissions to the first printer you plug into the USB system. That is not neccessarily what the user wants. I think this might be a good time to consider the devd/devfs distribution of work. The reason devfs(8) works like firewall rules is that we did not want some mandatory daemon to set the modes, in particular on embedded systems. The alternative solution is to always create device nodes root:wheel r-- and let the daemon set the mode as desired. This model has the advantage of not needing the uid, gid and mode arguments to make_dev, something that has always been acknowleded as a kludge. The down side is that devd(8) becomes a mandatory daemon on most systems. A downside which belongs into its own discussion, an not into the already huge back and forth for the new USB subsystem. Given that devfs(8) has not exactly been a stellar success and that it often and repeatedly bites people with it slightly pedantic semantics, transitioning in that direction might be a good thing. Unpredictable behavior (except you know by heard which entry is behaving how... something someone should not need to know) instead of doing it right by doing all at once? I don't think this is a good idea, and it seems Warner thinks the same (see his answer to the mail you answered to). Bye, Alexander. -- Ferengi Rule of Acquisition #177: Know your enemies... but do business with them always. -- ST: Legends of the Ferengi http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/123224: commit references a PR
The following reply was made to PR kern/123224; it has been noted by GNATS. From: [EMAIL PROTECTED] (dfilter service) To: [EMAIL PROTECTED] Cc: Subject: Re: kern/123224: commit references a PR Date: Sat, 23 Aug 2008 17:33:13 + (UTC) kaiw2008-08-23 17:32:43 UTC FreeBSD src repository Modified files:(Branch: RELENG_7) sys/dev/usb ums.c Log: SVN rev 182072 on 2008-08-23 17:32:43Z by kaiw MFC r181839: Re-add Microsoft Intellimouse 2.0 TWHEEL quirk. Tested by: Merritt Draney, Brian Cox PR: kern/123224 PR: kern/123510 Revision ChangesPath 1.96.2.4 +3 -0 src/sys/dev/usb/ums.c ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/123510: commit references a PR
The following reply was made to PR kern/123510; it has been noted by GNATS. From: [EMAIL PROTECTED] (dfilter service) To: [EMAIL PROTECTED] Cc: Subject: Re: kern/123510: commit references a PR Date: Sat, 23 Aug 2008 17:33:13 + (UTC) kaiw2008-08-23 17:32:43 UTC FreeBSD src repository Modified files:(Branch: RELENG_7) sys/dev/usb ums.c Log: SVN rev 182072 on 2008-08-23 17:32:43Z by kaiw MFC r181839: Re-add Microsoft Intellimouse 2.0 TWHEEL quirk. Tested by: Merritt Draney, Brian Cox PR: kern/123224 PR: kern/123510 Revision ChangesPath 1.96.2.4 +3 -0 src/sys/dev/usb/ums.c ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/125941: commit references a PR
The following reply was made to PR usb/125941; it has been noted by GNATS. From: [EMAIL PROTECTED] (dfilter service) To: [EMAIL PROTECTED] Cc: Subject: Re: usb/125941: commit references a PR Date: Sat, 23 Aug 2008 17:38:46 + (UTC) kaiw2008-08-23 17:38:24 UTC FreeBSD src repository Modified files:(Branch: RELENG_7) sys/dev/usb hid.c Log: SVN rev 182074 on 2008-08-23 17:38:24Z by kaiw MFC r181841: In the hid parser, if a INPUT/OUTPUT/FEATURE item is skipped, its corresponding USAGE should be skipped as well. Tested by:Grzegorz Blach PR: usb/125941 Revision ChangesPath 1.29.2.1 +12 -3 src/sys/dev/usb/hid.c ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/125941: [ums] not working wheel on my microsoft notebook optical mouse 3000
Synopsis: [ums] not working wheel on my microsoft notebook optical mouse 3000 State-Changed-From-To: open-closed State-Changed-By: kaiw State-Changed-When: Sat Aug 23 18:17:27 UTC 2008 State-Changed-Why: Patch committed. http://www.freebsd.org/cgi/query-pr.cgi?pr=125941 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/123224: [ums] Scroll wheel breakage w/ USB MS Wireless Intellimouse Explorer 2.0
Synopsis: [ums] Scroll wheel breakage w/ USB MS Wireless Intellimouse Explorer 2.0 State-Changed-From-To: open-closed State-Changed-By: kaiw State-Changed-When: Sat Aug 23 18:50:55 UTC 2008 State-Changed-Why: Patched. http://www.freebsd.org/cgi/query-pr.cgi?pr=123224 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/123510: [ums] Mouse Wheel Fails to Work [regression]
Synopsis: [ums] Mouse Wheel Fails to Work [regression] State-Changed-From-To: open-closed State-Changed-By: kaiw State-Changed-When: Sat Aug 23 18:51:35 UTC 2008 State-Changed-Why: Patched. http://www.freebsd.org/cgi/query-pr.cgi?pr=123510 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Microsoft Wireless Optical Desktop 3000 doesn't work correctly
Hi, Andrew!
Recently. I had a similar problem with Microsoft Wireless MultiMedia Keyboard
1.1 and FreeBSD 7.0 i386
Below the letter my ums.c that working correctly with this hardware.
My modifications of ums.c was inspired by
http://accima.com/members/dhesser/fbsd_mouse_stuff/
The most significant modification in this source file is:
else
if (
id-bInterfaceClass == UICLASS_HID
uaa-product == 0x009d
uaa-vendor == 0x045e
uaa-ifaceno == 1 // iface0 for keyboard, iface1 for mice
){
id-bInterfaceSubClass = UISUBCLASS_BOOT;
id-bInterfaceProtocol = UIPROTO_MOUSE;
printf(\nMicosoft Wireles Desktop Mouse\n);
ret = UMATCH_IFACECLASS;
}
Please, keep in mind, that I wrote product and vendor code especially for my
hardware. You may have to use another values.
Have a good time,
Alexander Makarenkov
/*-
* Copyright (c) 1998 The NetBSD Foundation, Inc.
* All rights reserved.
*
* This code is derived from software contributed to The NetBSD Foundation
* by Lennart Augustsson ([EMAIL PROTECTED]) at
* Carlstedt Research Technology.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
*must display the following acknowledgement:
*This product includes software developed by the NetBSD
*Foundation, Inc. and its contributors.
* 4. Neither the name of The NetBSD Foundation nor the names of its
*contributors may be used to endorse or promote products derived
*from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
* ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
* TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
#include sys/cdefs.h
__FBSDID($FreeBSD: src/sys/dev/usb/ums.c,v 1.96.2.3 2008/06/12 16:45:46 kaiw
Exp $);
/*
* HID spec: http://www.usb.org/developers/devclass_docs/HID1_11.pdf
*/
#include sys/param.h
#include sys/systm.h
#include sys/kernel.h
#include sys/malloc.h
#include sys/module.h
#include sys/bus.h
#include sys/ioccom.h
#include sys/conf.h
#include sys/fcntl.h
#include sys/tty.h
#include sys/file.h
#include sys/selinfo.h
#include sys/poll.h
#include sys/sysctl.h
#include sys/uio.h
#include dev/usb/usb.h
#include dev/usb/usbhid.h
#include dev/usb/usbdi.h
#include dev/usb/usbdi_util.h
#include usbdevs.h
#include dev/usb/usb_quirks.h
#include dev/usb/hid.h
#include sys/mouse.h
#ifdef USB_DEBUG
#define DPRINTF(x) if (umsdebug) printf x
#define DPRINTFN(n,x) if (umsdebug(n)) printf x
int umsdebug = 0;
SYSCTL_NODE(_hw_usb, OID_AUTO, ums, CTLFLAG_RW, 0, USB ums);
SYSCTL_INT(_hw_usb_ums, OID_AUTO, debug, CTLFLAG_RW,
umsdebug, 0, ums debug level);
#else
#define DPRINTF(x)
#define DPRINTFN(n,x)
#endif
#define UMSUNIT(s) (minor(s)0x1f)
#define MS_TO_TICKS(ms) ((ms) * hz / 1000)
#define QUEUE_BUFSIZE 400 /* MUST be divisible by 5 _and_ 8 */
struct ums_softc {
device_t sc_dev;/* base device */
usbd_interface_handle sc_iface; /* interface */
usbd_pipe_handle sc_intrpipe; /* interrupt pipe */
int sc_ep_addr;
u_char *sc_ibuf;
u_int8_t sc_iid;
int sc_isize;
struct hid_location sc_loc_x, sc_loc_y, sc_loc_z, sc_loc_t, sc_loc_w;
struct hid_location *sc_loc_btn;
struct callout callout_handle; /* for spurious button ups */
int sc_enabled;
int sc_disconnected;/* device is gone */
int flags; /* device configuration */
#define UMS_Z 0x01/* z direction available */
#define UMS_SPUR_BUT_UP 0x02/* spurious button up events */
#define UMS_T 0x04/* aa direction available (tilt) */
#define UMS_REVZ
Re: usb4bsd patch review
In message: [EMAIL PROTECTED] Poul-Henning Kamp [EMAIL PROTECTED] writes: : In message [EMAIL PROTECTED], M. Warner Losh writes : : : : While this may be a good idea, I'm hesitant about races that it may : introduce. This is the classic point of attack: do something between : steps of a formerly atomic operation that was made non-atomic. I : can't think of anything off the top of my head, but I'm still : concerned. : : We have ways of closing the race if need be, but they're all slightly : kludgy, but I am not overly concerned about those races as long as : the default is to not give access. I guess I'm worried about a device that comes and goes and comes back and there being some difference between the two that causes us to bogusly do something to the new device that was appropriate for the old one, but not the new one... Wraner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP new usb code coming in.
In message: [EMAIL PROTECTED] Antony Mawer [EMAIL PROTECTED] writes: : On 23/08/2008 8:08 PM, Volker wrote: : On 12/23/-58 20:59, Antony Mawer wrote: : M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Antony Mawer [EMAIL PROTECTED] writes: : : Warner Losh wrote: : : From: Bakul Shah [EMAIL PROTECTED] : : Subject: Re: HEADSUP new usb code coming in. : Date: Tue, 19 Aug : 2008 14:18:13 -0700 : : : On Tue, 19 Aug 2008 22:44:20 +0200 Hans Petter Selasky : [EMAIL PROTECTED] wrote: : : New stuff (all of which I can remember right now): : : ... : : : : Accidentally unplugging a mounted USB disk (without : : unmounting it) resulted in a hang or a crash. Is this fixed? : : : That's fixed in -current right now with the old stack. It : isn't a usb : : issue at all, but a buffer cache issue. : : : Is this change that is likely to be MFC'd in time for 7.1? And/or : is : there a specific patch that can manually be applied to -STABLE to : fix this? : : I should spend the time to dig into the changes in current. There : turned out to be several little changes... And I need to verify all : the edge cases were covered... : I'd be happy to test patches if you do end up doing this.. it would be : really nice to have in 7.1, or at least available as a patchset if it : isn't suitable for MFC (eg. ABI changes)... : : I'm a bit behind with reading emails. Please forgive me if this has : already been answered. : : Don't expect the new USB stack for 7.1-R. It's too short and the new USB : stack will introduce an ABI breakage. For that, all drivers written for : the old USB stack need to be rewritten and I guess, we need to take care : about 3rd party developers and inform them in advance about that massive : change. I would not wonder if this will never get MFC'd but I don't know : actually. : : This wasn't about the new USB stack -- we were discussing the buffer : cache and CAM-related fixes that prevents the system from panic'ing when : a USB device is unplugged without first unmounting the filesystem. These : patches are in HEAD with the existing USB stack. :-) The best I can do is say Maybe and the answer is closer to yes if somebody data-mines the changes I've made in this area in -current. That's the hard part of back porting them.. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
