Re: Official Linux system wrapper library?
On 24/11/18 1:53 am, Szabolcs Nagy wrote: On 23/11/18 14:11, David Newall wrote: On 24/11/18 12:04 am, Florian Weimer wrote: But socketcall does not exist on all architectures. Neither does getpid, it's called getxpid on some architectures. ... I think it would be a poor approach to expose application developers to these portability issues. We need to abstract over these differences at a certain layer, and applications are too late. Interesting. I think the opposite. I think exposing the OS's interfaces is exactly what a c-library should do. It might also provide alternative interfaces that work consistently across different platforms, but in addition to, not instead of the OS interface. you don't understand the point of the c language if you think so. I understand the point of C, thank you very much, and we're talking about the C library, not the language. I don't understand the point of your rudeness.
Re: Official Linux system wrapper library?
On 24/11/18 1:53 am, Szabolcs Nagy wrote: On 23/11/18 14:11, David Newall wrote: On 24/11/18 12:04 am, Florian Weimer wrote: But socketcall does not exist on all architectures. Neither does getpid, it's called getxpid on some architectures. ... I think it would be a poor approach to expose application developers to these portability issues. We need to abstract over these differences at a certain layer, and applications are too late. Interesting. I think the opposite. I think exposing the OS's interfaces is exactly what a c-library should do. It might also provide alternative interfaces that work consistently across different platforms, but in addition to, not instead of the OS interface. you don't understand the point of the c language if you think so. I understand the point of C, thank you very much, and we're talking about the C library, not the language. I don't understand the point of your rudeness.
Re: Official Linux system wrapper library?
On 24/11/18 12:04 am, Florian Weimer wrote: But socketcall does not exist on all architectures. Neither does getpid, it's called getxpid on some architectures. ... I think it would be a poor approach to expose application developers to these portability issues. We need to abstract over these differences at a certain layer, and applications are too late. Interesting. I think the opposite. I think exposing the OS's interfaces is exactly what a c-library should do. It might also provide alternative interfaces that work consistently across different platforms, but in addition to, not instead of the OS interface.
Re: Official Linux system wrapper library?
On 24/11/18 12:04 am, Florian Weimer wrote: But socketcall does not exist on all architectures. Neither does getpid, it's called getxpid on some architectures. ... I think it would be a poor approach to expose application developers to these portability issues. We need to abstract over these differences at a certain layer, and applications are too late. Interesting. I think the opposite. I think exposing the OS's interfaces is exactly what a c-library should do. It might also provide alternative interfaces that work consistently across different platforms, but in addition to, not instead of the OS interface.
copying file results in out of memory, kills other processes, makes system unavailable
Hi all, First, I'm not subscribed to any of the mailing lists addressed. Please copy me in replies. I'm not sure if this is an LVM issue or a MM issue. I rather think it's the latter, and I'll explain why, towards the end of this email. I'm running a qemu virtual machine, 2 x i686 with 2GB RAM. VM's disks are managed via LVM2. Most disk activity is on one LV, formatted as ext4. Backups are taken using snapshots, and at the time of the problem that I am about to describe, there were ten of them, or so. OS is Ubuntu 12.04 with current everything. Kernel was 3.8.0-42-generic, by Canonical's reckoning, and I've possibly reproduced it with a vanilla 3.14.7-031407-generic from kernel.ubuntu.com. Applications include CUPS, SSH, Samba, Denyhosts and an accounting package compiled using RM-COBOL. Normally the system runs with no use of swap (2GB configured) and about half of physical RAM free. CPU usage is normally around 99.9% idle. This is not a demanding application for the machine! Physical machine is 8 x amd64, 32GB RAM, Ubuntu 14.04, kernel 3.13.0-24-generic. I mention this, but think it not relevant. The problem presented as machine unavailable. It would accept connections on SSH, but Openssh did not display it's banner (SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.2.) All terminals froze and, having configured ServerAlive*, eventually disconnected. The VM was configured using libvirt, which showed that machine running at 200% CPU usage; i.e. 100% x 2 CPUs. As the machine was mission critical, I elected to kill and restart it. I suspect I would have had no alternative, even had I had the luxury of unlimited time to investigate. After restart, I (predictably) found nothing unusual in the logs. Part of the restart process included running a program to "clear 98 errors" (clear98.) It produced some output as it went, but didn't complete: the machine again went in to this "busy" state. I restarted the machine and noticed that a couple of snapshots had reached 100% on their COW tables, removed them and reran clear98, with the same results: machine became unresponsive and busy. Actually, I think it got slightly further, but not by much. Restarting again, I found another snapshot had reached 100% on COW table, removed it, and reran clear98. Whilst running, I kept an eye on snapshots and removed them as they exceeded 85% on COW table. Accordingly, all snapshots were removed and the program completed successfully. Examining syslog, I found that later incidents were caused by out of memory condition. The process identified by oom-killer was unrelated to clear98 (it was a bash script invoked by an incoming SSH connection.) Jun 11 11:50:17 crowies kernel: [ 838.952607] Mem-Info: Jun 11 11:50:17 crowies kernel: [ 838.952609] DMA per-cpu: Jun 11 11:50:17 crowies kernel: [ 838.952611] CPU0: hi:0, btch: 1 usd: 0 Jun 11 11:50:17 crowies kernel: [ 838.952612] CPU1: hi:0, btch: 1 usd: 0 Jun 11 11:50:17 crowies kernel: [ 838.952613] Normal per-cpu: Jun 11 11:50:17 crowies kernel: [ 838.952615] CPU0: hi: 186, btch: 31 usd: 0 Jun 11 11:50:17 crowies kernel: [ 838.952616] CPU1: hi: 186, btch: 31 usd: 0 Jun 11 11:50:17 crowies kernel: [ 838.952617] HighMem per-cpu: Jun 11 11:50:17 crowies kernel: [ 838.952618] CPU0: hi: 186, btch: 31 usd: 0 Jun 11 11:50:17 crowies kernel: [ 838.952620] CPU1: hi: 186, btch: 31 usd: 0 Jun 11 11:50:17 crowies kernel: [ 838.952623] active_anon:11693 inactive_anon:11899 isolated_anon:0 Jun 11 11:50:17 crowies kernel: [ 838.952623] active_file:152931 inactive_file:100402 isolated_file:0 Jun 11 11:50:17 crowies kernel: [ 838.952623] unevictable:0 dirty:5 writeback:8204 unstable:0 Jun 11 11:50:17 crowies kernel: [ 838.952623] free:23425 slab_reclaimable:2164 slab_unreclaimable:121333 Jun 11 11:50:17 crowies kernel: [ 838.952623] mapped:5100 shmem:173 pagetables:1076 bounce:0 Jun 11 11:50:17 crowies kernel: [ 838.952623] free_cma:0 Jun 11 11:50:17 crowies kernel: [ 838.952630] DMA free:4068kB min:784kB low:980kB high:1176kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15804kB managed:15916kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:8788kB kernel_stack:40kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes Jun 11 11:50:17 crowies kernel: [ 838.952631] lowmem_reserve[]: 0 869 2016 2016 Jun 11 11:50:17 crowies kernel: [ 838.952638] Normal free:43464kB min:44216kB low:55268kB high:66324kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:104kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:890008kB managed:844872kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:8656kB slab_unreclaimable:476544kB
copying file results in out of memory, kills other processes, makes system unavailable
Hi all, First, I'm not subscribed to any of the mailing lists addressed. Please copy me in replies. I'm not sure if this is an LVM issue or a MM issue. I rather think it's the latter, and I'll explain why, towards the end of this email. I'm running a qemu virtual machine, 2 x i686 with 2GB RAM. VM's disks are managed via LVM2. Most disk activity is on one LV, formatted as ext4. Backups are taken using snapshots, and at the time of the problem that I am about to describe, there were ten of them, or so. OS is Ubuntu 12.04 with current everything. Kernel was 3.8.0-42-generic, by Canonical's reckoning, and I've possibly reproduced it with a vanilla 3.14.7-031407-generic from kernel.ubuntu.com. Applications include CUPS, SSH, Samba, Denyhosts and an accounting package compiled using RM-COBOL. Normally the system runs with no use of swap (2GB configured) and about half of physical RAM free. CPU usage is normally around 99.9% idle. This is not a demanding application for the machine! Physical machine is 8 x amd64, 32GB RAM, Ubuntu 14.04, kernel 3.13.0-24-generic. I mention this, but think it not relevant. The problem presented as machine unavailable. It would accept connections on SSH, but Openssh did not display it's banner (SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.2.) All terminals froze and, having configured ServerAlive*, eventually disconnected. The VM was configured using libvirt, which showed that machine running at 200% CPU usage; i.e. 100% x 2 CPUs. As the machine was mission critical, I elected to kill and restart it. I suspect I would have had no alternative, even had I had the luxury of unlimited time to investigate. After restart, I (predictably) found nothing unusual in the logs. Part of the restart process included running a program to clear 98 errors (clear98.) It produced some output as it went, but didn't complete: the machine again went in to this busy state. I restarted the machine and noticed that a couple of snapshots had reached 100% on their COW tables, removed them and reran clear98, with the same results: machine became unresponsive and busy. Actually, I think it got slightly further, but not by much. Restarting again, I found another snapshot had reached 100% on COW table, removed it, and reran clear98. Whilst running, I kept an eye on snapshots and removed them as they exceeded 85% on COW table. Accordingly, all snapshots were removed and the program completed successfully. Examining syslog, I found that later incidents were caused by out of memory condition. The process identified by oom-killer was unrelated to clear98 (it was a bash script invoked by an incoming SSH connection.) Jun 11 11:50:17 crowies kernel: [ 838.952607] Mem-Info: Jun 11 11:50:17 crowies kernel: [ 838.952609] DMA per-cpu: Jun 11 11:50:17 crowies kernel: [ 838.952611] CPU0: hi:0, btch: 1 usd: 0 Jun 11 11:50:17 crowies kernel: [ 838.952612] CPU1: hi:0, btch: 1 usd: 0 Jun 11 11:50:17 crowies kernel: [ 838.952613] Normal per-cpu: Jun 11 11:50:17 crowies kernel: [ 838.952615] CPU0: hi: 186, btch: 31 usd: 0 Jun 11 11:50:17 crowies kernel: [ 838.952616] CPU1: hi: 186, btch: 31 usd: 0 Jun 11 11:50:17 crowies kernel: [ 838.952617] HighMem per-cpu: Jun 11 11:50:17 crowies kernel: [ 838.952618] CPU0: hi: 186, btch: 31 usd: 0 Jun 11 11:50:17 crowies kernel: [ 838.952620] CPU1: hi: 186, btch: 31 usd: 0 Jun 11 11:50:17 crowies kernel: [ 838.952623] active_anon:11693 inactive_anon:11899 isolated_anon:0 Jun 11 11:50:17 crowies kernel: [ 838.952623] active_file:152931 inactive_file:100402 isolated_file:0 Jun 11 11:50:17 crowies kernel: [ 838.952623] unevictable:0 dirty:5 writeback:8204 unstable:0 Jun 11 11:50:17 crowies kernel: [ 838.952623] free:23425 slab_reclaimable:2164 slab_unreclaimable:121333 Jun 11 11:50:17 crowies kernel: [ 838.952623] mapped:5100 shmem:173 pagetables:1076 bounce:0 Jun 11 11:50:17 crowies kernel: [ 838.952623] free_cma:0 Jun 11 11:50:17 crowies kernel: [ 838.952630] DMA free:4068kB min:784kB low:980kB high:1176kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15804kB managed:15916kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:8788kB kernel_stack:40kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes Jun 11 11:50:17 crowies kernel: [ 838.952631] lowmem_reserve[]: 0 869 2016 2016 Jun 11 11:50:17 crowies kernel: [ 838.952638] Normal free:43464kB min:44216kB low:55268kB high:66324kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:104kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:890008kB managed:844872kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:8656kB slab_unreclaimable:476544kB
Re: Revert 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge : Sanitize skb before it enters the IP stack)
On 20/05/14 14:25, valdis.kletni...@vt.edu wrote: So yes, we*do* need to do something sensible there - either frag the packet on the way out, or something. I think the problem is that a bridge cannot be used across incompatible media. That's the job of a router. A bridge should act like a bridge, not a router. Fragmenting the packet is wrong; that's IP's job. Dropping the packet is also arguably wrong; that's the real device-driver's job. What seems right to me is to act like a bridge and forward packets by looking inside of them *no more than is necessary*. Looking beyond MAC address is perhaps too much. We can finish the job of processing IP options, or at least in this scenario, but that seems wrong-headed and invites more work as more problems are discovered; or we could remove the half-hearted attempt it currently does and leave the bridge as a simple bridge. This problem wouldn't occur if all devices in a bridge were required to be compatible media; particularly identical MTU. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Revert 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge : Sanitize skb before it enters the IP stack)
On 20/05/14 14:25, valdis.kletni...@vt.edu wrote: So yes, we*do* need to do something sensible there - either frag the packet on the way out, or something. I think the problem is that a bridge cannot be used across incompatible media. That's the job of a router. A bridge should act like a bridge, not a router. Fragmenting the packet is wrong; that's IP's job. Dropping the packet is also arguably wrong; that's the real device-driver's job. What seems right to me is to act like a bridge and forward packets by looking inside of them *no more than is necessary*. Looking beyond MAC address is perhaps too much. We can finish the job of processing IP options, or at least in this scenario, but that seems wrong-headed and invites more work as more problems are discovered; or we could remove the half-hearted attempt it currently does and leave the bridge as a simple bridge. This problem wouldn't occur if all devices in a bridge were required to be compatible media; particularly identical MTU. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Revert 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge : Sanitize skb before it enters the IP stack)
Thanks for the reply. I've been hanging out for it! On 19/05/14 23:31, Florian Westphal wrote: Well, did you test what happens if we try to refrag a packet containing ip options after the revert? can happen e.g. when using netfilter conntrack on top of a bridge. No. I expect it would panic, as was reported prior to the commit. I tried to persevere with the commit: I recalculated checksum, which left routes and times improperly updated in options. Then I tried calling ip_forward_options, which looks like it would correctly update RR and TS (not to mention checksum)m but that bombed because skb_rtable returned NULL. I think calling skb_set_dst would answer that, but I don't know how to get a valid dst. (I asked for help but no answer.) I see three ways to progress: 1. Possibly call ip_forward_option, but that requires somebody who understands this code to help; 2. Just recalculate the checksum, leaving crap in the options; or 3. Revert the commit. Option 1 doesn't look like it's going to happen; option 2 is stupid; leaving option 3, and I begin to think that's the right way to go if bridge is supposed to be a bridge and not a router. The idea that bridge is doing too much seems to have quite a lot of currency, so think of reversion as chopping off a canker. Or we keep fixing bugs, adding to bridge, until it replicates all of IP. How does a packet get fragmented in this case? Does it only happen when bridging to a device with smaller MTU? That scenario sounds quite un-bridge-like. It also sounds like something that can be handled by real routing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Revert 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge : Sanitize skb before it enters the IP stack)
Having received no feedback of substance from netdev, I now address my
previous email to a wider audience for discussion and in preparation for
submitting a patch based closely on that below.
This email is not addressed to Bandan Das , who
is the author of the commit I propose reverting, as his email address is
no longer current. I believe I have otherwise addressed all appropriate
recipients and will circulate a formal patch to the same recipients if
no adverse comments are received. (That would surprise me.)
Original Message
Subject: Revert 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge :
Sanitize skb before it enters the IP stack)
Date: Sat, 17 May 2014 00:03:16 +0930
From: David Newall
To: Lukas Tribus , Eric Dumazet
, Netdev
CC: f...@strlen.de
We should revert commit 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge
: Sanitize skb before it enters the IP stack) because it corrupts IP
packets with RR or TS options set, only partially updating the IP header
and leaving an incorrect checksum.
The argument for introducing the change is at lkml.org/lkml/2010/8/30/391:
The bridge layer can overwrite the IPCB using the
BR_INPUT_SKB_CB macro. In br_nf_dev_queue_xmit,
if we recieve a packet greater in size than the bridge
device MTU, we call ip_fragment which in turn will lead to
icmp_send calling ip_options_echo if the DF flag is set.
ip_options_echo will then incorrectly try to parse the IPCB as
IP options resulting in a buffer overflow.
This change refills the CB area back with IP
options before ip_fragment calls icmp_send. If we fail parsing,
we zero out the IPCB area to guarantee that the stack does
not get corrupted.
A bridge should not fragment packets; an *ethernet* bridge should not
need to. Fragmenting packets is the job of higher level protocol.
--- br_netfilter.c 2014-01-20 13:10:07.0 +1030
+++ br_netfilter.c.prop 2014-05-16 23:07:57.975386905 +0930
@@ -253,73 +253,6 @@
skb->protocol = htons(ETH_P_PPP_SES);
}
-/* When handing a packet over to the IP layer
- * check whether we have a skb that is in the
- * expected format
- */
-
-static int br_parse_ip_options(struct sk_buff *skb)
-{
- struct ip_options *opt;
- const struct iphdr *iph;
- struct net_device *dev = skb->dev;
- u32 len;
-
- if (!pskb_may_pull(skb, sizeof(struct iphdr)))
- goto inhdr_error;
-
- iph = ip_hdr(skb);
- opt = &(IPCB(skb)->opt);
-
- /* Basic sanity checks */
- if (iph->ihl < 5 || iph->version != 4)
- goto inhdr_error;
-
- if (!pskb_may_pull(skb, iph->ihl*4))
- goto inhdr_error;
-
- iph = ip_hdr(skb);
- if (unlikely(ip_fast_csum((u8 *)iph, iph->ihl)))
- goto inhdr_error;
-
- len = ntohs(iph->tot_len);
- if (skb->len < len) {
- IP_INC_STATS_BH(dev_net(dev), IPSTATS_MIB_INTRUNCATEDPKTS);
- goto drop;
- } else if (len < (iph->ihl*4))
- goto inhdr_error;
-
- if (pskb_trim_rcsum(skb, len)) {
- IP_INC_STATS_BH(dev_net(dev), IPSTATS_MIB_INDISCARDS);
- goto drop;
- }
-
- memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
- if (iph->ihl == 5)
- return 0;
-
- opt->optlen = iph->ihl*4 - sizeof(struct iphdr);
- if (ip_options_compile(dev_net(dev), opt, skb))
- goto inhdr_error;
-
- /* Check correct handling of SRR option */
- if (unlikely(opt->srr)) {
- struct in_device *in_dev = __in_dev_get_rcu(dev);
- if (in_dev && !IN_DEV_SOURCE_ROUTE(in_dev))
- goto drop;
-
- if (ip_options_rcv_srr(skb))
- goto drop;
- }
-
- return 0;
-
-inhdr_error:
- IP_INC_STATS_BH(dev_net(dev), IPSTATS_MIB_INHDRERRORS);
-drop:
- return -1;
-}
-
/* Fill in the header for fragmented IP packets handled by
* the IPv4 connection tracking code.
*/
@@ -679,6 +612,7 @@
{
struct net_bridge_port *p;
struct net_bridge *br;
+ const struct iphdr *iph;
__u32 len = nf_bridge_encap_header_len(skb);
if (unlikely(!pskb_may_pull(skb, len)))
@@ -704,9 +638,29 @@
return NF_ACCEPT;
nf_bridge_pull_encap_header_rcsum(skb);
+
+ if (!pskb_may_pull(skb, sizeof(struct iphdr)))
+ goto inhdr_error;
- if (br_parse_ip_options(skb))
- return NF_DROP;
+ iph = ip_hdr(skb);
+ if (iph->ihl < 5 || iph->version != 4)
+ goto inhdr_error;
+
+ if (!pskb_may_pull(skb, 4 * iph->ihl))
+ goto inhdr_error;
+
+ iph = ip_hdr(skb);
+ if (ip_fast_csum((__u8 *) iph, iph->ihl) != 0)
+ goto inhdr_error;
+
+ len = ntohs(iph->tot_len);
+ if (skb->len < len || l
Revert 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge : Sanitize skb before it enters the IP stack)
Having received no feedback of substance from netdev, I now address my
previous email to a wider audience for discussion and in preparation for
submitting a patch based closely on that below.
This email is not addressed to Bandan Das bandan@stratus.com, who
is the author of the commit I propose reverting, as his email address is
no longer current. I believe I have otherwise addressed all appropriate
recipients and will circulate a formal patch to the same recipients if
no adverse comments are received. (That would surprise me.)
Original Message
Subject: Revert 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge :
Sanitize skb before it enters the IP stack)
Date: Sat, 17 May 2014 00:03:16 +0930
From: David Newall dav...@davidnewall.com
To: Lukas Tribus luky...@hotmail.com, Eric Dumazet
eric.duma...@gmail.com, Netdev net...@vger.kernel.org
CC: f...@strlen.de f...@strlen.de
We should revert commit 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge
: Sanitize skb before it enters the IP stack) because it corrupts IP
packets with RR or TS options set, only partially updating the IP header
and leaving an incorrect checksum.
The argument for introducing the change is at lkml.org/lkml/2010/8/30/391:
The bridge layer can overwrite the IPCB using the
BR_INPUT_SKB_CB macro. In br_nf_dev_queue_xmit,
if we recieve a packet greater in size than the bridge
device MTU, we call ip_fragment which in turn will lead to
icmp_send calling ip_options_echo if the DF flag is set.
ip_options_echo will then incorrectly try to parse the IPCB as
IP options resulting in a buffer overflow.
This change refills the CB area back with IP
options before ip_fragment calls icmp_send. If we fail parsing,
we zero out the IPCB area to guarantee that the stack does
not get corrupted.
A bridge should not fragment packets; an *ethernet* bridge should not
need to. Fragmenting packets is the job of higher level protocol.
--- br_netfilter.c 2014-01-20 13:10:07.0 +1030
+++ br_netfilter.c.prop 2014-05-16 23:07:57.975386905 +0930
@@ -253,73 +253,6 @@
skb-protocol = htons(ETH_P_PPP_SES);
}
-/* When handing a packet over to the IP layer
- * check whether we have a skb that is in the
- * expected format
- */
-
-static int br_parse_ip_options(struct sk_buff *skb)
-{
- struct ip_options *opt;
- const struct iphdr *iph;
- struct net_device *dev = skb-dev;
- u32 len;
-
- if (!pskb_may_pull(skb, sizeof(struct iphdr)))
- goto inhdr_error;
-
- iph = ip_hdr(skb);
- opt = (IPCB(skb)-opt);
-
- /* Basic sanity checks */
- if (iph-ihl 5 || iph-version != 4)
- goto inhdr_error;
-
- if (!pskb_may_pull(skb, iph-ihl*4))
- goto inhdr_error;
-
- iph = ip_hdr(skb);
- if (unlikely(ip_fast_csum((u8 *)iph, iph-ihl)))
- goto inhdr_error;
-
- len = ntohs(iph-tot_len);
- if (skb-len len) {
- IP_INC_STATS_BH(dev_net(dev), IPSTATS_MIB_INTRUNCATEDPKTS);
- goto drop;
- } else if (len (iph-ihl*4))
- goto inhdr_error;
-
- if (pskb_trim_rcsum(skb, len)) {
- IP_INC_STATS_BH(dev_net(dev), IPSTATS_MIB_INDISCARDS);
- goto drop;
- }
-
- memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
- if (iph-ihl == 5)
- return 0;
-
- opt-optlen = iph-ihl*4 - sizeof(struct iphdr);
- if (ip_options_compile(dev_net(dev), opt, skb))
- goto inhdr_error;
-
- /* Check correct handling of SRR option */
- if (unlikely(opt-srr)) {
- struct in_device *in_dev = __in_dev_get_rcu(dev);
- if (in_dev !IN_DEV_SOURCE_ROUTE(in_dev))
- goto drop;
-
- if (ip_options_rcv_srr(skb))
- goto drop;
- }
-
- return 0;
-
-inhdr_error:
- IP_INC_STATS_BH(dev_net(dev), IPSTATS_MIB_INHDRERRORS);
-drop:
- return -1;
-}
-
/* Fill in the header for fragmented IP packets handled by
* the IPv4 connection tracking code.
*/
@@ -679,6 +612,7 @@
{
struct net_bridge_port *p;
struct net_bridge *br;
+ const struct iphdr *iph;
__u32 len = nf_bridge_encap_header_len(skb);
if (unlikely(!pskb_may_pull(skb, len)))
@@ -704,9 +638,29 @@
return NF_ACCEPT;
nf_bridge_pull_encap_header_rcsum(skb);
+
+ if (!pskb_may_pull(skb, sizeof(struct iphdr)))
+ goto inhdr_error;
- if (br_parse_ip_options(skb))
- return NF_DROP;
+ iph = ip_hdr(skb);
+ if (iph-ihl 5 || iph-version != 4)
+ goto inhdr_error;
+
+ if (!pskb_may_pull(skb, 4 * iph-ihl))
+ goto inhdr_error;
+
+ iph = ip_hdr(skb);
+ if (ip_fast_csum((__u8 *) iph, iph-ihl) != 0)
+ goto inhdr_error;
+
+ len = ntohs(iph-tot_len);
+ if (skb-len len || len
Re: Revert 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge : Sanitize skb before it enters the IP stack)
Thanks for the reply. I've been hanging out for it! On 19/05/14 23:31, Florian Westphal wrote: Well, did you test what happens if we try to refrag a packet containing ip options after the revert? can happen e.g. when using netfilter conntrack on top of a bridge. No. I expect it would panic, as was reported prior to the commit. I tried to persevere with the commit: I recalculated checksum, which left routes and times improperly updated in options. Then I tried calling ip_forward_options, which looks like it would correctly update RR and TS (not to mention checksum)m but that bombed because skb_rtable returned NULL. I think calling skb_set_dst would answer that, but I don't know how to get a valid dst. (I asked for help but no answer.) I see three ways to progress: 1. Possibly call ip_forward_option, but that requires somebody who understands this code to help; 2. Just recalculate the checksum, leaving crap in the options; or 3. Revert the commit. Option 1 doesn't look like it's going to happen; option 2 is stupid; leaving option 3, and I begin to think that's the right way to go if bridge is supposed to be a bridge and not a router. The idea that bridge is doing too much seems to have quite a lot of currency, so think of reversion as chopping off a canker. Or we keep fixing bugs, adding to bridge, until it replicates all of IP. How does a packet get fragmented in this case? Does it only happen when bridging to a device with smaller MTU? That scenario sounds quite un-bridge-like. It also sounds like something that can be handled by real routing. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Fundamental flaw in system suspend, exposed by freezer removal
David Brownell wrote: > On Tuesday 26 February 2008, David Newall wrote: > >> Hardware can be inserted and removed while we're in a suspend state; and >> there's nothing that we can do about it until we resume. Is it fair to >> say, then, that having started suspend, we could reasonably ignore any >> device insertion and removal, and handle it on resume? >> > > "Ignore" seems a bit strong; those events may be wakeup triggers, > which would cause the hardware to make it a very short suspend state. > > "Defer handling" is more to the point, be it by hardware or software. > > Of course, "defer". The insertion has to be handled eventually. What I'm wondering is if we can ignore it, and catch it on the resume. >> Presumably we need to scan for hardware changes on resume. >> > > Not on most busses I work with; the hardware issues notifications > whenever the devices are removable. > There's no notification while we're suspended. Isn't it necessary to scan all busses on resume, just to know what's on them? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Fundamental flaw in system suspend, exposed by freezer removal
David Brownell wrote: > This "flaw" isn't a new thing, of course. I remember pointing out the rather > annoying proclivity of the PM framework to deadlock when suspend() tried to > remove USB devices ... back around 2.6.10 or so. Things have shuffled around > a bit, and gotten better in some cases, but not fundamentally changed. Hardware can be inserted and removed while we're in a suspend state; and there's nothing that we can do about it until we resume. Is it fair to say, then, that having started suspend, we could reasonably ignore any device insertion and removal, and handle it on resume? Presumably we need to scan for hardware changes on resume. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Fundamental flaw in system suspend, exposed by freezer removal
David Brownell wrote: This flaw isn't a new thing, of course. I remember pointing out the rather annoying proclivity of the PM framework to deadlock when suspend() tried to remove USB devices ... back around 2.6.10 or so. Things have shuffled around a bit, and gotten better in some cases, but not fundamentally changed. Hardware can be inserted and removed while we're in a suspend state; and there's nothing that we can do about it until we resume. Is it fair to say, then, that having started suspend, we could reasonably ignore any device insertion and removal, and handle it on resume? Presumably we need to scan for hardware changes on resume. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Fundamental flaw in system suspend, exposed by freezer removal
David Brownell wrote: On Tuesday 26 February 2008, David Newall wrote: Hardware can be inserted and removed while we're in a suspend state; and there's nothing that we can do about it until we resume. Is it fair to say, then, that having started suspend, we could reasonably ignore any device insertion and removal, and handle it on resume? Ignore seems a bit strong; those events may be wakeup triggers, which would cause the hardware to make it a very short suspend state. Defer handling is more to the point, be it by hardware or software. Of course, defer. The insertion has to be handled eventually. What I'm wondering is if we can ignore it, and catch it on the resume. Presumably we need to scan for hardware changes on resume. Not on most busses I work with; the hardware issues notifications whenever the devices are removable. There's no notification while we're suspended. Isn't it necessary to scan all busses on resume, just to know what's on them? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging of completely unreviewed drivers
Linus Torvalds wrote:
> On Sat, 23 Feb 2008, David Newall wrote:
>
>> Do you actually get 80 columns wide on it?
>>
>
> Do people really care that deeply?
> ...
> And do I find lines longer than 80 charactes unreadable? Hell no.
>
I care, yes. I've found my code looks much prettier, with attendant
improvement in ease of understanding, since I stopped being so anal
about 80 columns. The width of the code, that is first to last
non-blank on each line, is about the same, not because I work to keep
it narrow, but because most statements just are narrow. Sometimes I do
get really wide statements, for example when using deep data structures,
especially as parameters in procedure calls, and this is easier to read
than having to break the line.
I honestly think the reason we used to insist on lines less than 80
characters was because on an 80 character screen, you get slightly
better readability by choosing where to break each line than simply
letting the hardware do it. We don't have the physical limit any more,
so we don't need to impose it structurally.
It's about readability, and with due respect, people who've never tried
it aren't qualified to comment.
> which talks more about what matters - too deep indentation.
What's too deep? Is the following too deep? It's common enough, other
than my refusal to relax consistent indenting style for switch bodies.
The code is readable, and breaking it into multiple procedures just to
de-indent is often impossible, and rarely readable. With a strict 80
character limit, the meat in the sandwich is left with only 20 or so
characters in which to fit. Add a nested switch, and there's virtually
no space left for code.
123456789012345678901234567890123456789012345678901234567890123456 (70)
int procedure(param list)
{
switch (condition)
{
case value:
if (another_condition)
{
if (variant)
meat_in_sandwich;
} else {
code;
}
case value2:
switch (sub_condition)
{
case sub_value:
if (final_test)
{
something(
NULL,
1,
"two");
}
}
}
}
(Yes, I know, "we don't indent 'case' because it consumes too much
room." That's inconsistent with the rest of normal indenting style, and
a poor excuse to keep within an obsolete and unnecessary restriction.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Merging of completely unreviewed drivers
Jan Engelhardt wrote:
> static void blah(void)
> {
> if (foo) {
> bar;
> bar2;
> return;
> }
> if (this) {
> that;
> that2;
> return;
> }
> /* yay, got rid of two levels of indent! */
> good day;
> good day2;
> }
I like this style. It's more readable than the alternative that you
showed. If you hate returns mid-procedure, as some purists do, the
following is also good:
static void blah(void)
{
if (foo) {
bar;
bar2;
} else if (this) {
that;
that2;
} else {
good day;
good day2;
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Merging of completely unreviewed drivers
Pavel Machek wrote: > On Sat 2008-02-23 23:08:58, David Newall wrote: > >> Pavel Machek wrote: >> >>> On Fri 2008-02-22 23:44:09, Krzysztof Halasa wrote: >>> >>> >>>> Pavel Machek <[EMAIL PROTECTED]> writes: >>>> >>>> >>>> >>>>> Zaurus is one example, second is small screen where you need big font >>>>> to keep it readable (x60 on desk). >>>>> >>>>> >>>> Come on, are you doing Linux kernel development on PDA? >>>> > > Actually, I'd like to. There's a lot to fix on zaurus. Bit corruption > while sleeping is high on list, but I guess I should move out of > 2.6.16, first. > > >>> I review patches on it, sometimes, yes. >>> >>> >> Do you actually get 80 columns wide on it? >> > > No, something like 62... but it is usually enough. x60 is about 100 > columns wide (big font needed). Then it's a silly example to raise in a serious discussion of this type. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accessor macros vs reference counting
Matthew Wilcox wrote: > On Sat, Feb 23, 2008 at 04:14:08PM +0800, WANG Cong wrote: > >> Use get_personality() macro instead of explicit reference >> for parisc code. >> -if (personality(current->personality) == PER_LINUX32 >> +if (personality(get_personality()) == PER_LINUX32 >> > > Hm. We have an interesting clash of conventions here. > > On the one hand, we have the java-style accessor convention. > get_personality()/set_personality(). > Is get_personality() thought to be better than current->personality? To me, the latter seems more meaningful, and I'd rather see it than the former. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging of completely unreviewed drivers
Pavel Machek wrote: > On Fri 2008-02-22 23:44:09, Krzysztof Halasa wrote: > >> Pavel Machek <[EMAIL PROTECTED]> writes: >> >> >>> Zaurus is one example, second is small screen where you need big font >>> to keep it readable (x60 on desk). >>> >> Come on, are you doing Linux kernel development on PDA? >> > > I review patches on it, sometimes, yes. > Do you actually get 80 columns wide on it? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging of completely unreviewed drivers
Pavel Machek wrote: On Fri 2008-02-22 23:44:09, Krzysztof Halasa wrote: Pavel Machek [EMAIL PROTECTED] writes: Zaurus is one example, second is small screen where you need big font to keep it readable (x60 on desk). Come on, are you doing Linux kernel development on PDA? I review patches on it, sometimes, yes. Do you actually get 80 columns wide on it? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accessor macros vs reference counting
Matthew Wilcox wrote: On Sat, Feb 23, 2008 at 04:14:08PM +0800, WANG Cong wrote: Use get_personality() macro instead of explicit reference for parisc code. -if (personality(current-personality) == PER_LINUX32 +if (personality(get_personality()) == PER_LINUX32 Hm. We have an interesting clash of conventions here. On the one hand, we have the java-style accessor convention. get_personality()/set_personality(). Is get_personality() thought to be better than current-personality? To me, the latter seems more meaningful, and I'd rather see it than the former. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging of completely unreviewed drivers
Pavel Machek wrote: On Sat 2008-02-23 23:08:58, David Newall wrote: Pavel Machek wrote: On Fri 2008-02-22 23:44:09, Krzysztof Halasa wrote: Pavel Machek [EMAIL PROTECTED] writes: Zaurus is one example, second is small screen where you need big font to keep it readable (x60 on desk). Come on, are you doing Linux kernel development on PDA? Actually, I'd like to. There's a lot to fix on zaurus. Bit corruption while sleeping is high on list, but I guess I should move out of 2.6.16, first. I review patches on it, sometimes, yes. Do you actually get 80 columns wide on it? No, something like 62... but it is usually enough. x60 is about 100 columns wide (big font needed). Then it's a silly example to raise in a serious discussion of this type. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging of completely unreviewed drivers
Jan Engelhardt wrote:
static void blah(void)
{
if (foo) {
bar;
bar2;
return;
}
if (this) {
that;
that2;
return;
}
/* yay, got rid of two levels of indent! */
good day;
good day2;
}
I like this style. It's more readable than the alternative that you
showed. If you hate returns mid-procedure, as some purists do, the
following is also good:
static void blah(void)
{
if (foo) {
bar;
bar2;
} else if (this) {
that;
that2;
} else {
good day;
good day2;
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Merging of completely unreviewed drivers
Linus Torvalds wrote:
On Sat, 23 Feb 2008, David Newall wrote:
Do you actually get 80 columns wide on it?
Do people really care that deeply?
...
And do I find lines longer than 80 charactes unreadable? Hell no.
I care, yes. I've found my code looks much prettier, with attendant
improvement in ease of understanding, since I stopped being so anal
about 80 columns. The width of the code, that is first to last
non-blank on each line, is about the same, not because I work to keep
it narrow, but because most statements just are narrow. Sometimes I do
get really wide statements, for example when using deep data structures,
especially as parameters in procedure calls, and this is easier to read
than having to break the line.
I honestly think the reason we used to insist on lines less than 80
characters was because on an 80 character screen, you get slightly
better readability by choosing where to break each line than simply
letting the hardware do it. We don't have the physical limit any more,
so we don't need to impose it structurally.
It's about readability, and with due respect, people who've never tried
it aren't qualified to comment.
which talks more about what matters - too deep indentation.
What's too deep? Is the following too deep? It's common enough, other
than my refusal to relax consistent indenting style for switch bodies.
The code is readable, and breaking it into multiple procedures just to
de-indent is often impossible, and rarely readable. With a strict 80
character limit, the meat in the sandwich is left with only 20 or so
characters in which to fit. Add a nested switch, and there's virtually
no space left for code.
123456789012345678901234567890123456789012345678901234567890123456 (70)
int procedure(param list)
{
switch (condition)
{
case value:
if (another_condition)
{
if (variant)
meat_in_sandwich;
} else {
code;
}
case value2:
switch (sub_condition)
{
case sub_value:
if (final_test)
{
something(
NULL,
1,
two);
}
}
}
}
(Yes, I know, we don't indent 'case' because it consumes too much
room. That's inconsistent with the rest of normal indenting style, and
a poor excuse to keep within an obsolete and unnecessary restriction.)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ofa-general] Re: Merging of completely unreviewed drivers
Bart Van Assche wrote: > There is a reason to limit line length: scientific research has shown > that readability of regular texts is optimal for a line length between > 55 and 65 characters. Putting aside the point that we're talking code, not regular text, I've heard that said before and I don't think it's quite like that. Perhaps the numbers you said might assume various things such as the width of the eye's field of view, the distance to the image and the size of each character? > My experience is that the readability of source > code decreases when the lines are very long (more than 160 > characters). The point is that the width, excluding leading and trailing white space, is what really matters. Even deeply indented code can be a snap to understand if you don't have to fight artificial line breaks. And we've got a much wider -- and taller! -- space available than we had in the old 80x24 (and 80x1) days. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ofa-general] Re: Merging of completely unreviewed drivers
Bart Van Assche wrote: There is a reason to limit line length: scientific research has shown that readability of regular texts is optimal for a line length between 55 and 65 characters. Putting aside the point that we're talking code, not regular text, I've heard that said before and I don't think it's quite like that. Perhaps the numbers you said might assume various things such as the width of the eye's field of view, the distance to the image and the size of each character? My experience is that the readability of source code decreases when the lines are very long (more than 160 characters). The point is that the width, excluding leading and trailing white space, is what really matters. Even deeply indented code can be a snap to understand if you don't have to fight artificial line breaks. And we've got a much wider -- and taller! -- space available than we had in the old 80x24 (and 80x1) days. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging of completely unreviewed drivers
Krzysztof Halasa wrote: > Linus Torvalds <[EMAIL PROTECTED]> writes: >> I'm personally of the opinion that a lot of checkpatch "fixes" are >> anything but. That mainly concerns fixing overlong lines >> > > Perhaps we should increase line length limit, 132 should be fine. > Especially useful with long printk() lines and long arithmetic > expressions. > Yes; or even longer. 80 characters might have made sense on a screen when the alternative was 80 characters on a punched card, but on a modern computer it's very restrictive. That's especially true with the deep indents that you quickly get in C. Even short lines often need to be split when you put a few tabs in front of them, and that makes comprehension that bit harder, not to mention looks ugly. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.4: Back-port of pl2303.c from 2.6.24.1
Greg KH wrote: > On Thu, Feb 21, 2008 at 10:00:58PM +0100, Willy Tarreau wrote: > >> I too agree to merge, it especially since it fixed several problems >> for David. However, I would like to know first if the same problems >> also happen with the 2.6 driver or if it is OK. The risk is getting >> 2.4 fixed and not 2.6, which could cause regressions for people upgrading >> from 2.4 to 2.6. Of course, a regression on a USB-serial adapter is >> not dramatic, but it's a general principle to keep in mind that 2.6 >> should be safe (or at least actively being fixed) when merging driver >> changes in 2.4. >> > > As far as I can tell, this was a backport of the current 2.6 driver, so > it should not have fixes that are not already in 2.6. > > David, is that true? > That is true. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.4: Back-port of pl2303.c from 2.6.24.1
Sorry, I forgot to include the changes to pl2303.h. Here's a second patch: --- pl2303.h.orig 2008-01-01 22:36:40.0 +1030 +++ pl2303.h2008-02-22 06:11:19.0 +1030 @@ -9,7 +9,10 @@ */ #define PL2303_VENDOR_ID 0x067b #define PL2303_PRODUCT_ID 0x2303 -#define PL2303_PRODUCT_ID_RSAQ20x04bb +#define PL2303_PRODUCT_ID_RSAQ20x04bb +#define PL2303_PRODUCT_ID_DCU110x1234 +#define PL2303_PRODUCT_ID_PHAROS 0xaaa0 +#define PL2303_PRODUCT_ID_RSAQ30xaaa2 #define ATEN_VENDOR_ID 0x0557 #define ATEN_VENDOR_ID20x0547 @@ -17,18 +20,22 @@ #define IODATA_VENDOR_ID 0x04bb #define IODATA_PRODUCT_ID 0x0a03 +#define IODATA_PRODUCT_ID_RSAQ50x0a0e #define ELCOM_VENDOR_ID0x056e #define ELCOM_PRODUCT_ID 0x5003 +#define ELCOM_PRODUCT_ID_UCSGT 0x5004 #define ITEGNO_VENDOR_ID 0x0eba #define ITEGNO_PRODUCT_ID 0x1080 +#define ITEGNO_PRODUCT_ID_2080 0x2080 #define MA620_VENDOR_ID0x0df7 #define MA620_PRODUCT_ID 0x0620 #define RATOC_VENDOR_ID0x0584 #define RATOC_PRODUCT_ID 0xb000 +#define RATOC_PRODUCT_ID_USB60F0xb020 #define TRIPP_VENDOR_ID0x2478 #define TRIPP_PRODUCT_ID 0x2008 @@ -41,3 +48,67 @@ #define SITECOM_VENDOR_ID 0x6189 #define SITECOM_PRODUCT_ID 0x2068 + +/* Alcatel OT535/735 USB cable */ +#define ALCATEL_VENDOR_ID 0x11f7 +#define ALCATEL_PRODUCT_ID 0x02df + +/* Samsung I330 phone cradle */ +#define SAMSUNG_VENDOR_ID 0x04e8 +#define SAMSUNG_PRODUCT_ID 0x8001 + +#define SIEMENS_VENDOR_ID 0x11f5 +#define SIEMENS_PRODUCT_ID_SX1 0x0001 +#define SIEMENS_PRODUCT_ID_X65 0x0003 +#define SIEMENS_PRODUCT_ID_X75 0x0004 +#define SIEMENS_PRODUCT_ID_EF810x0005 + +#define SYNTECH_VENDOR_ID 0x0745 +#define SYNTECH_PRODUCT_ID 0x0001 + +/* Nokia CA-42 Cable */ +#define NOKIA_CA42_VENDOR_ID 0x078b +#define NOKIA_CA42_PRODUCT_ID 0x1234 + +/* CA-42 CLONE Cable www.ca-42.com chipset: Prolific Technology Inc */ +#define CA_42_CA42_VENDOR_ID 0x10b5 +#define CA_42_CA42_PRODUCT_ID 0xac70 + +#define SAGEM_VENDOR_ID0x079b +#define SAGEM_PRODUCT_ID 0x0027 + +/* Leadtek GPS 9531 (ID 0413:2101) */ +#define LEADTEK_VENDOR_ID 0x0413 +#define LEADTEK_9531_PRODUCT_ID0x2101 + +/* USB GSM cable from Speed Dragon Multimedia, Ltd */ +#define SPEEDDRAGON_VENDOR_ID 0x0e55 +#define SPEEDDRAGON_PRODUCT_ID 0x110b + +/* DATAPILOT Universal-2 Phone Cable */ +#define DATAPILOT_U2_VENDOR_ID 0x0731 +#define DATAPILOT_U2_PRODUCT_ID0x2003 + +/* Belkin "F5U257" Serial Adapter */ +#define BELKIN_VENDOR_ID 0x050d +#define BELKIN_PRODUCT_ID 0x0257 + +/* Alcor Micro Corp. USB 2.0 TO RS-232 */ +#define ALCOR_VENDOR_ID0x058F +#define ALCOR_PRODUCT_ID 0x9720 + +/* Willcom WS002IN Data Driver (by NetIndex Inc.) */ +#define WS002IN_VENDOR_ID 0x11f6 +#define WS002IN_PRODUCT_ID 0x2001 + +/* Corega CG-USBRS232R Serial Adapter */ +#define COREGA_VENDOR_ID 0x07aa +#define COREGA_PRODUCT_ID 0x002a + +/* HL HL-340 (ID: 4348:5523) */ +#define HL340_VENDOR_ID0x4348 +#define HL340_PRODUCT_ID 0x5523 + +/* Y.C. Cable U.S.A., Inc - USB to RS-232 */ +#define YCCABLE_VENDOR_ID 0x05ad +#define YCCABLE_PRODUCT_ID 0x0fba -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.4: Back-port of pl2303.c from 2.6.24.1
Hi Willy,
Lacking hardware for a week, I've had a bit of a hiatus from PL2303, but
I've got it back again now, and finished my work back-porting the 2.6
driver to 2.4. Here's a new patch, which is more complete than my
previous one. It's based on the 2.6.24.1.
There's a lot of trivial white-space changes and some things that have
been moved, which make the patch rather larger than it could be. I
didn't include those changes before, but have now in order that the
driver be closer to the 2.6 driver. It'll never be identical, of course.
Note, too, that the 2.6 driver (and thus the patched 2.4) includes a 1k
circular buffer which rather duplicates a buffer in the 2.4 usbserial.c;
2.6's usb-serial has had that buffer removed. As the buffer resolves
loss of the occasional putchar (e.g. from n_tty's opost), it is
important and correct, even in 2.4.
Speaking as a user, I no longer see any problems with PL2303, and I
think this is okay to release.
Regards,
David
--- pl2303.orig.c 2008-01-01 22:36:40.0 +1030
+++ pl2303.c2008-02-22 06:15:23.0 +1030
@@ -1,17 +1,20 @@
/*
* Prolific PL2303 USB to serial adaptor driver
*
- * Copyright (C) 2001-2003 Greg Kroah-Hartman ([EMAIL PROTECTED])
+ * Copyright (C) 2001-2007 Greg Kroah-Hartman ([EMAIL PROTECTED])
* Copyright (C) 2003 IBM Corp.
*
* Original driver for 2.2.x by anonymous
*
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
*
* See Documentation/usb/usb-serial.txt for more information on using this
driver
+ *
+ * 2008_Feb)22 dn
+ * Back-port pl2303.c from linux-2.6.24.1. [EMAIL PROTECTED]
+ *
* 2003_Apr_24 gkh
* Added line error reporting support. Hopefully it is correct...
*
@@ -33,6 +36,9 @@
*
*/
+/* TODO first char received is lost on second open of device. anecdotal
evidence
+ * TODO suggests this might be on all even opens of device. dn. */
+
#include
#include
#include
@@ -59,30 +65,64 @@
/*
* Version Information
*/
-#define DRIVER_VERSION "v0.10.1" /* Takes from 2.6's */
#define DRIVER_DESC "Prolific PL2303 USB to serial adaptor driver"
+#define PL2303_CLOSING_WAIT(30*HZ)
+#define PL2303_BUF_SIZE1024
+#define PL2303_TMP_BUF_SIZE1024
+
+struct pl2303_buf {
+ unsigned intbuf_size;
+ char*buf_buf;
+ char*buf_get;
+ char*buf_put;
+};
static struct usb_device_id id_table [] = {
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID) },
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_RSAQ2) },
+ { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_DCU11) },
+ { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_RSAQ3) },
+ { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_PHAROS) },
{ USB_DEVICE(IODATA_VENDOR_ID, IODATA_PRODUCT_ID) },
+ { USB_DEVICE(IODATA_VENDOR_ID, IODATA_PRODUCT_ID_RSAQ5) },
{ USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_ID) },
{ USB_DEVICE(ATEN_VENDOR_ID2, ATEN_PRODUCT_ID) },
{ USB_DEVICE(ELCOM_VENDOR_ID, ELCOM_PRODUCT_ID) },
+ { USB_DEVICE(ELCOM_VENDOR_ID, ELCOM_PRODUCT_ID_UCSGT) },
{ USB_DEVICE(ITEGNO_VENDOR_ID, ITEGNO_PRODUCT_ID) },
+ { USB_DEVICE(ITEGNO_VENDOR_ID, ITEGNO_PRODUCT_ID_2080) },
{ USB_DEVICE(MA620_VENDOR_ID, MA620_PRODUCT_ID) },
{ USB_DEVICE(RATOC_VENDOR_ID, RATOC_PRODUCT_ID) },
+ { USB_DEVICE(RATOC_VENDOR_ID, RATOC_PRODUCT_ID_USB60F) },
{ USB_DEVICE(TRIPP_VENDOR_ID, TRIPP_PRODUCT_ID) },
{ USB_DEVICE(RADIOSHACK_VENDOR_ID, RADIOSHACK_PRODUCT_ID) },
{ USB_DEVICE(DCU10_VENDOR_ID, DCU10_PRODUCT_ID) },
{ USB_DEVICE(SITECOM_VENDOR_ID, SITECOM_PRODUCT_ID) },
+ { USB_DEVICE(ALCATEL_VENDOR_ID, ALCATEL_PRODUCT_ID) },
+ { USB_DEVICE(SAMSUNG_VENDOR_ID, SAMSUNG_PRODUCT_ID) },
+ { USB_DEVICE(SIEMENS_VENDOR_ID, SIEMENS_PRODUCT_ID_SX1) },
+ { USB_DEVICE(SIEMENS_VENDOR_ID, SIEMENS_PRODUCT_ID_X65) },
+ { USB_DEVICE(SIEMENS_VENDOR_ID, SIEMENS_PRODUCT_ID_X75) },
+ { USB_DEVICE(SIEMENS_VENDOR_ID, SIEMENS_PRODUCT_ID_EF81) },
+ { USB_DEVICE(SYNTECH_VENDOR_ID, SYNTECH_PRODUCT_ID) },
+ { USB_DEVICE(NOKIA_CA42_VENDOR_ID, NOKIA_CA42_PRODUCT_ID) },
+ { USB_DEVICE(CA_42_CA42_VENDOR_ID, CA_42_CA42_PRODUCT_ID) },
+ { USB_DEVICE(SAGEM_VENDOR_ID, SAGEM_PRODUCT_ID) },
+ { USB_DEVICE(LEADTEK_VENDOR_ID, LEADTEK_9531_PRODUCT_ID) },
+ { USB_DEVICE(SPEEDDRAGON_VENDOR_ID, SPEEDDRAGON_PRODUCT_ID) },
+ { USB_DEVICE(DATAPILOT_U2_VENDOR_ID, DATAPILOT_U2_PRODUCT_ID) },
Re: Handshaking on USB serial devices
Alan Cox wrote: >> developing is entirely wrong. Oh well. Mind you, providing a >> write_room function is NOT a real solution; it merely reduces the >> condition to a usually-winnable race. (Ironically, when I back-ported >> the 2.6 driver, I excluded its new write_room function. Mistake.) >> > > What race do you see left ? > On second thoughts I'm not sure that I do. I've had my head so full of 2.4 pl2303, and 2.4 pl2303 with this, that and the other added to it, that I was probably just confused. Certainly it's not important, because I didn't mean the 2.6 driver, but an hypothetical 2.4 with a simplistic write_room function added (e.g. return port->write_urb->status == -EINPROGRESS ? 0 : 64). OPOST processing's use of putchar to expand CRLF sends two writes (or putchars), with no intervening checks. Since I'm just polishing off my back-port of 2.6.24.1 pl2303 to kernel 2.4, the matter is quite irrelevant. By the way, what happened to HUawei E620 UMTS/HSDPA card? It's in pl2303 in 2.6.23; not in 2.6.24.1. (Do I remove it from my back-port?) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Handshaking on USB serial devices
Alan,
Alan Cox wrote:
>> That's a very good point. Even so: on the 2.4 driver, write_room isn't
>> implemented (refer to a previous message by Alan); and in 2.6, a 1k
>> buffer is built into the driver, with nothing to prevent it being sent
>> when the hardware buffer fills.
>>
[...]
> Careful - a lot of hardware handles this properly itself, you simply
> don't get the URB completing until its all done.
>
I am incredibly grateful to you for telling me this. I didn't know it
and hadn't noticed that that was occurring; it was. I thought data was
being lost by the converter -- I could see where it was missing on the
screen! -- but it's actually a bug in the tty layer.
Here's what really was happening: The PL2303 contains a 256 byte buffer,
and write URBs don't complete when that's full, as you said. At such
times, that is when a bulk write was pending, the tty layer could and
would still call pl2303_write, which would return 0. The tty layer
would loop, trying one byte followed by the remaining count, repeating
until no data remained. The following clause, from write_chan in
n_tty.c, appears responsible; it is within a while(1) loop:
if (O_OPOST(tty) && !(test_bit(TTY_HW_COOK_OUT, >flags))) {
while (nr > 0) {
ssize_t num = opost_block(tty, b, nr);
if (num < 0) {
if (num == -EAGAIN)
break;
retval = num;
goto break_out;
}
b += num;
nr -= num;
if (nr == 0)
break;
get_user(c, b);
if (opost(c, tty) < 0)
break;
b++; nr--;
}
if (tty->driver.flush_chars)
tty->driver.flush_chars(tty);
} ...
Note that opost() assumes that driver.putchar (which translates to a
one-byte write) always succeeds. This behaviour is documented.
By the way, the true cause of the problem was somewhat disguised by the
fact that space in the PL2303's buffer could become available part-way
through the cycle, causing non-deterministic (i.e. not exactly
reproducible) loss of part of a write; it looked exactly like a flow
control problem.
The (2.4, remember) PL2303 driver has no write_room function, which I
gather is the appropriate place to signal that a write cannot be
performed. Providing one that returns 0 when the (singleton) write urb
is busy, resolves the issue. The patch that I had previously been
developing is entirely wrong. Oh well. Mind you, providing a
write_room function is NOT a real solution; it merely reduces the
condition to a usually-winnable race. (Ironically, when I back-ported
the 2.6 driver, I excluded its new write_room function. Mistake.)
Thanks for the nugget.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Handshaking on USB serial devices
Alan,
Alan Cox wrote:
That's a very good point. Even so: on the 2.4 driver, write_room isn't
implemented (refer to a previous message by Alan); and in 2.6, a 1k
buffer is built into the driver, with nothing to prevent it being sent
when the hardware buffer fills.
[...]
Careful - a lot of hardware handles this properly itself, you simply
don't get the URB completing until its all done.
I am incredibly grateful to you for telling me this. I didn't know it
and hadn't noticed that that was occurring; it was. I thought data was
being lost by the converter -- I could see where it was missing on the
screen! -- but it's actually a bug in the tty layer.
Here's what really was happening: The PL2303 contains a 256 byte buffer,
and write URBs don't complete when that's full, as you said. At such
times, that is when a bulk write was pending, the tty layer could and
would still call pl2303_write, which would return 0. The tty layer
would loop, trying one byte followed by the remaining count, repeating
until no data remained. The following clause, from write_chan in
n_tty.c, appears responsible; it is within a while(1) loop:
if (O_OPOST(tty) !(test_bit(TTY_HW_COOK_OUT, tty-flags))) {
while (nr 0) {
ssize_t num = opost_block(tty, b, nr);
if (num 0) {
if (num == -EAGAIN)
break;
retval = num;
goto break_out;
}
b += num;
nr -= num;
if (nr == 0)
break;
get_user(c, b);
if (opost(c, tty) 0)
break;
b++; nr--;
}
if (tty-driver.flush_chars)
tty-driver.flush_chars(tty);
} ...
Note that opost() assumes that driver.putchar (which translates to a
one-byte write) always succeeds. This behaviour is documented.
By the way, the true cause of the problem was somewhat disguised by the
fact that space in the PL2303's buffer could become available part-way
through the cycle, causing non-deterministic (i.e. not exactly
reproducible) loss of part of a write; it looked exactly like a flow
control problem.
The (2.4, remember) PL2303 driver has no write_room function, which I
gather is the appropriate place to signal that a write cannot be
performed. Providing one that returns 0 when the (singleton) write urb
is busy, resolves the issue. The patch that I had previously been
developing is entirely wrong. Oh well. Mind you, providing a
write_room function is NOT a real solution; it merely reduces the
condition to a usually-winnable race. (Ironically, when I back-ported
the 2.6 driver, I excluded its new write_room function. Mistake.)
Thanks for the nugget.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Handshaking on USB serial devices
Alan Cox wrote: developing is entirely wrong. Oh well. Mind you, providing a write_room function is NOT a real solution; it merely reduces the condition to a usually-winnable race. (Ironically, when I back-ported the 2.6 driver, I excluded its new write_room function. Mistake.) What race do you see left ? On second thoughts I'm not sure that I do. I've had my head so full of 2.4 pl2303, and 2.4 pl2303 with this, that and the other added to it, that I was probably just confused. Certainly it's not important, because I didn't mean the 2.6 driver, but an hypothetical 2.4 with a simplistic write_room function added (e.g. return port-write_urb-status == -EINPROGRESS ? 0 : 64). OPOST processing's use of putchar to expand CRLF sends two writes (or putchars), with no intervening checks. Since I'm just polishing off my back-port of 2.6.24.1 pl2303 to kernel 2.4, the matter is quite irrelevant. By the way, what happened to HUawei E620 UMTS/HSDPA card? It's in pl2303 in 2.6.23; not in 2.6.24.1. (Do I remove it from my back-port?) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.4: Back-port of pl2303.c from 2.6.24.1
Hi Willy,
Lacking hardware for a week, I've had a bit of a hiatus from PL2303, but
I've got it back again now, and finished my work back-porting the 2.6
driver to 2.4. Here's a new patch, which is more complete than my
previous one. It's based on the 2.6.24.1.
There's a lot of trivial white-space changes and some things that have
been moved, which make the patch rather larger than it could be. I
didn't include those changes before, but have now in order that the
driver be closer to the 2.6 driver. It'll never be identical, of course.
Note, too, that the 2.6 driver (and thus the patched 2.4) includes a 1k
circular buffer which rather duplicates a buffer in the 2.4 usbserial.c;
2.6's usb-serial has had that buffer removed. As the buffer resolves
loss of the occasional putchar (e.g. from n_tty's opost), it is
important and correct, even in 2.4.
Speaking as a user, I no longer see any problems with PL2303, and I
think this is okay to release.
Regards,
David
--- pl2303.orig.c 2008-01-01 22:36:40.0 +1030
+++ pl2303.c2008-02-22 06:15:23.0 +1030
@@ -1,17 +1,20 @@
/*
* Prolific PL2303 USB to serial adaptor driver
*
- * Copyright (C) 2001-2003 Greg Kroah-Hartman ([EMAIL PROTECTED])
+ * Copyright (C) 2001-2007 Greg Kroah-Hartman ([EMAIL PROTECTED])
* Copyright (C) 2003 IBM Corp.
*
* Original driver for 2.2.x by anonymous
*
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
*
* See Documentation/usb/usb-serial.txt for more information on using this
driver
+ *
+ * 2008_Feb)22 dn
+ * Back-port pl2303.c from linux-2.6.24.1. [EMAIL PROTECTED]
+ *
* 2003_Apr_24 gkh
* Added line error reporting support. Hopefully it is correct...
*
@@ -33,6 +36,9 @@
*
*/
+/* TODO first char received is lost on second open of device. anecdotal
evidence
+ * TODO suggests this might be on all even opens of device. dn. */
+
#include
#include
#include
@@ -59,30 +65,64 @@
/*
* Version Information
*/
-#define DRIVER_VERSION v0.10.1 /* Takes from 2.6's */
#define DRIVER_DESC Prolific PL2303 USB to serial adaptor driver
+#define PL2303_CLOSING_WAIT(30*HZ)
+#define PL2303_BUF_SIZE1024
+#define PL2303_TMP_BUF_SIZE1024
+
+struct pl2303_buf {
+ unsigned intbuf_size;
+ char*buf_buf;
+ char*buf_get;
+ char*buf_put;
+};
static struct usb_device_id id_table [] = {
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID) },
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_RSAQ2) },
+ { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_DCU11) },
+ { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_RSAQ3) },
+ { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_PHAROS) },
{ USB_DEVICE(IODATA_VENDOR_ID, IODATA_PRODUCT_ID) },
+ { USB_DEVICE(IODATA_VENDOR_ID, IODATA_PRODUCT_ID_RSAQ5) },
{ USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_ID) },
{ USB_DEVICE(ATEN_VENDOR_ID2, ATEN_PRODUCT_ID) },
{ USB_DEVICE(ELCOM_VENDOR_ID, ELCOM_PRODUCT_ID) },
+ { USB_DEVICE(ELCOM_VENDOR_ID, ELCOM_PRODUCT_ID_UCSGT) },
{ USB_DEVICE(ITEGNO_VENDOR_ID, ITEGNO_PRODUCT_ID) },
+ { USB_DEVICE(ITEGNO_VENDOR_ID, ITEGNO_PRODUCT_ID_2080) },
{ USB_DEVICE(MA620_VENDOR_ID, MA620_PRODUCT_ID) },
{ USB_DEVICE(RATOC_VENDOR_ID, RATOC_PRODUCT_ID) },
+ { USB_DEVICE(RATOC_VENDOR_ID, RATOC_PRODUCT_ID_USB60F) },
{ USB_DEVICE(TRIPP_VENDOR_ID, TRIPP_PRODUCT_ID) },
{ USB_DEVICE(RADIOSHACK_VENDOR_ID, RADIOSHACK_PRODUCT_ID) },
{ USB_DEVICE(DCU10_VENDOR_ID, DCU10_PRODUCT_ID) },
{ USB_DEVICE(SITECOM_VENDOR_ID, SITECOM_PRODUCT_ID) },
+ { USB_DEVICE(ALCATEL_VENDOR_ID, ALCATEL_PRODUCT_ID) },
+ { USB_DEVICE(SAMSUNG_VENDOR_ID, SAMSUNG_PRODUCT_ID) },
+ { USB_DEVICE(SIEMENS_VENDOR_ID, SIEMENS_PRODUCT_ID_SX1) },
+ { USB_DEVICE(SIEMENS_VENDOR_ID, SIEMENS_PRODUCT_ID_X65) },
+ { USB_DEVICE(SIEMENS_VENDOR_ID, SIEMENS_PRODUCT_ID_X75) },
+ { USB_DEVICE(SIEMENS_VENDOR_ID, SIEMENS_PRODUCT_ID_EF81) },
+ { USB_DEVICE(SYNTECH_VENDOR_ID, SYNTECH_PRODUCT_ID) },
+ { USB_DEVICE(NOKIA_CA42_VENDOR_ID, NOKIA_CA42_PRODUCT_ID) },
+ { USB_DEVICE(CA_42_CA42_VENDOR_ID, CA_42_CA42_PRODUCT_ID) },
+ { USB_DEVICE(SAGEM_VENDOR_ID, SAGEM_PRODUCT_ID) },
+ { USB_DEVICE(LEADTEK_VENDOR_ID, LEADTEK_9531_PRODUCT_ID) },
+ { USB_DEVICE(SPEEDDRAGON_VENDOR_ID, SPEEDDRAGON_PRODUCT_ID) },
+ { USB_DEVICE(DATAPILOT_U2_VENDOR_ID, DATAPILOT_U2_PRODUCT_ID) },
+
Re: [PATCH] 2.4: Back-port of pl2303.c from 2.6.24.1
Sorry, I forgot to include the changes to pl2303.h. Here's a second patch: --- pl2303.h.orig 2008-01-01 22:36:40.0 +1030 +++ pl2303.h2008-02-22 06:11:19.0 +1030 @@ -9,7 +9,10 @@ */ #define PL2303_VENDOR_ID 0x067b #define PL2303_PRODUCT_ID 0x2303 -#define PL2303_PRODUCT_ID_RSAQ20x04bb +#define PL2303_PRODUCT_ID_RSAQ20x04bb +#define PL2303_PRODUCT_ID_DCU110x1234 +#define PL2303_PRODUCT_ID_PHAROS 0xaaa0 +#define PL2303_PRODUCT_ID_RSAQ30xaaa2 #define ATEN_VENDOR_ID 0x0557 #define ATEN_VENDOR_ID20x0547 @@ -17,18 +20,22 @@ #define IODATA_VENDOR_ID 0x04bb #define IODATA_PRODUCT_ID 0x0a03 +#define IODATA_PRODUCT_ID_RSAQ50x0a0e #define ELCOM_VENDOR_ID0x056e #define ELCOM_PRODUCT_ID 0x5003 +#define ELCOM_PRODUCT_ID_UCSGT 0x5004 #define ITEGNO_VENDOR_ID 0x0eba #define ITEGNO_PRODUCT_ID 0x1080 +#define ITEGNO_PRODUCT_ID_2080 0x2080 #define MA620_VENDOR_ID0x0df7 #define MA620_PRODUCT_ID 0x0620 #define RATOC_VENDOR_ID0x0584 #define RATOC_PRODUCT_ID 0xb000 +#define RATOC_PRODUCT_ID_USB60F0xb020 #define TRIPP_VENDOR_ID0x2478 #define TRIPP_PRODUCT_ID 0x2008 @@ -41,3 +48,67 @@ #define SITECOM_VENDOR_ID 0x6189 #define SITECOM_PRODUCT_ID 0x2068 + +/* Alcatel OT535/735 USB cable */ +#define ALCATEL_VENDOR_ID 0x11f7 +#define ALCATEL_PRODUCT_ID 0x02df + +/* Samsung I330 phone cradle */ +#define SAMSUNG_VENDOR_ID 0x04e8 +#define SAMSUNG_PRODUCT_ID 0x8001 + +#define SIEMENS_VENDOR_ID 0x11f5 +#define SIEMENS_PRODUCT_ID_SX1 0x0001 +#define SIEMENS_PRODUCT_ID_X65 0x0003 +#define SIEMENS_PRODUCT_ID_X75 0x0004 +#define SIEMENS_PRODUCT_ID_EF810x0005 + +#define SYNTECH_VENDOR_ID 0x0745 +#define SYNTECH_PRODUCT_ID 0x0001 + +/* Nokia CA-42 Cable */ +#define NOKIA_CA42_VENDOR_ID 0x078b +#define NOKIA_CA42_PRODUCT_ID 0x1234 + +/* CA-42 CLONE Cable www.ca-42.com chipset: Prolific Technology Inc */ +#define CA_42_CA42_VENDOR_ID 0x10b5 +#define CA_42_CA42_PRODUCT_ID 0xac70 + +#define SAGEM_VENDOR_ID0x079b +#define SAGEM_PRODUCT_ID 0x0027 + +/* Leadtek GPS 9531 (ID 0413:2101) */ +#define LEADTEK_VENDOR_ID 0x0413 +#define LEADTEK_9531_PRODUCT_ID0x2101 + +/* USB GSM cable from Speed Dragon Multimedia, Ltd */ +#define SPEEDDRAGON_VENDOR_ID 0x0e55 +#define SPEEDDRAGON_PRODUCT_ID 0x110b + +/* DATAPILOT Universal-2 Phone Cable */ +#define DATAPILOT_U2_VENDOR_ID 0x0731 +#define DATAPILOT_U2_PRODUCT_ID0x2003 + +/* Belkin F5U257 Serial Adapter */ +#define BELKIN_VENDOR_ID 0x050d +#define BELKIN_PRODUCT_ID 0x0257 + +/* Alcor Micro Corp. USB 2.0 TO RS-232 */ +#define ALCOR_VENDOR_ID0x058F +#define ALCOR_PRODUCT_ID 0x9720 + +/* Willcom WS002IN Data Driver (by NetIndex Inc.) */ +#define WS002IN_VENDOR_ID 0x11f6 +#define WS002IN_PRODUCT_ID 0x2001 + +/* Corega CG-USBRS232R Serial Adapter */ +#define COREGA_VENDOR_ID 0x07aa +#define COREGA_PRODUCT_ID 0x002a + +/* HL HL-340 (ID: 4348:5523) */ +#define HL340_VENDOR_ID0x4348 +#define HL340_PRODUCT_ID 0x5523 + +/* Y.C. Cable U.S.A., Inc - USB to RS-232 */ +#define YCCABLE_VENDOR_ID 0x05ad +#define YCCABLE_PRODUCT_ID 0x0fba -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging of completely unreviewed drivers
Krzysztof Halasa wrote: Linus Torvalds [EMAIL PROTECTED] writes: I'm personally of the opinion that a lot of checkpatch fixes are anything but. That mainly concerns fixing overlong lines Perhaps we should increase line length limit, 132 should be fine. Especially useful with long printk() lines and long arithmetic expressions. Yes; or even longer. 80 characters might have made sense on a screen when the alternative was 80 characters on a punched card, but on a modern computer it's very restrictive. That's especially true with the deep indents that you quickly get in C. Even short lines often need to be split when you put a few tabs in front of them, and that makes comprehension that bit harder, not to mention looks ugly. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.4: Back-port of pl2303.c from 2.6.24.1
Greg KH wrote: On Thu, Feb 21, 2008 at 10:00:58PM +0100, Willy Tarreau wrote: I too agree to merge, it especially since it fixed several problems for David. However, I would like to know first if the same problems also happen with the 2.6 driver or if it is OK. The risk is getting 2.4 fixed and not 2.6, which could cause regressions for people upgrading from 2.4 to 2.6. Of course, a regression on a USB-serial adapter is not dramatic, but it's a general principle to keep in mind that 2.6 should be safe (or at least actively being fixed) when merging driver changes in 2.4. As far as I can tell, this was a backport of the current 2.6 driver, so it should not have fixes that are not already in 2.6. David, is that true? That is true. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PL2303 Driver missing support for USB to Serial Cable
Stephan, Jiri Slaby wrote: > On 02/14/2008 03:57 PM, Stephan Rose wrote: >> I recently purchased a USB->Com Port serial cable from Radio Shack >> (Model number 26-183) which did no seem to want to work. After looking >> into it I discovered that it is based on the Prolific chipset using the >> PL2303 driver. > > Well, would you mind creating, testing and posting a patch? You needn't bother. As far as I'm concerned, what you sent is sufficient and, as I am currently working on the pl2303 driver, you can rest assured that it will be included in the patch that I send. Regards, David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Driver removals
Adrian Bunk wrote: > Forks are allowed, so when you don't like the way some software is > developed you can always release a version of the software that is in > your eyes better. > What a silly thought. Nobody, I should hope, wants multiple Linuxes competing and diluting the market. That's what went wrong with UNIX, and it's what's wrong with BSD (and what gave Linux a foothold.) Read your history; and for goodness sake, the less said on this the better. > After all, free software is not driven by people whining but by people > doing stuff. Howling protest is not whining. The whining comes from those who want to kill the old driver, which is reported to be used, works well and is wanted. It sounds insecure to want to terminate one's competition with such extreme prejudice. Let the old driver die of natural causes, if that's its destiny. And don't whine if the new can't make it on its own merits. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Driver removals
Adrian Bunk wrote: Forks are allowed, so when you don't like the way some software is developed you can always release a version of the software that is in your eyes better. What a silly thought. Nobody, I should hope, wants multiple Linuxes competing and diluting the market. That's what went wrong with UNIX, and it's what's wrong with BSD (and what gave Linux a foothold.) Read your history; and for goodness sake, the less said on this the better. After all, free software is not driven by people whining but by people doing stuff. Howling protest is not whining. The whining comes from those who want to kill the old driver, which is reported to be used, works well and is wanted. It sounds insecure to want to terminate one's competition with such extreme prejudice. Let the old driver die of natural causes, if that's its destiny. And don't whine if the new can't make it on its own merits. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PL2303 Driver missing support for USB to Serial Cable
Stephan, Jiri Slaby wrote: On 02/14/2008 03:57 PM, Stephan Rose wrote: I recently purchased a USB-Com Port serial cable from Radio Shack (Model number 26-183) which did no seem to want to work. After looking into it I discovered that it is based on the Prolific chipset using the PL2303 driver. Well, would you mind creating, testing and posting a patch? You needn't bother. As far as I'm concerned, what you sent is sufficient and, as I am currently working on the pl2303 driver, you can rest assured that it will be included in the patch that I send. Regards, David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Handshaking on USB serial devices
Greg KH wrote: > On Thu, Feb 14, 2008 at 07:55:44PM +1030, David Newall wrote: > >> The current 2.6 driver maintains it's own buffer. I think that's a bad >> thing: usbserial already buffers writes, and the extra buffer copy seems >> unnecessary, however it does solve the putchar problem. Buffered (i.e. >> by the 2.6 series pl2303 driver) data is written as soon as practicable, >> regardless of CTS/DTR. The same general workaround, but placed in >> pl2303_send seems correct to me; that is, stop submitting write urbs >> when the remote end lowers CTS/DTR, and trigger the resume from the >> interrupt callback (specifically in update_line_status.) >> > > Where does the usbserial core buffer writes on 2.6? The serial_write() > function just passes the data straight down to the usb-serial child > driver directly, no copying or buffering happens that I can see. > You're right. I haven't examined the 2.6 stack as closely as the 2.4. I noticed the buffer in 2.6 pl2303, but didn't check 2.6 usb-serial. I think I prefer the buffer in usb-serial, because its centralised rather than in each driver, but I'm not going to step up to the plate and propose changing that! >> To make it clear: Even aside from the buffer in 2.6's pl2303.c, there's >> a race: An in-flight write URB can fill all hardware buffers, making >> unsafe what previously appeared to be a safe write. I think it's >> essential to delay submission of the URB on a stop-transmit condition. >> > > It's up to the individual driver to know when their buffers are filled > up. The big problem is, a lot of these cheap usb-serial devices (like > the pl2303) don't have a way to report the uart queue filled-state back > to the host, so things can easily get over-run as you have found out. > My understanding of the problem has developed over the last couple of days; going from wrist-deep to elbow-deep into the guts of things does that. There is a problem, and the solution I've been developing addresses it, but maybe there's a simpler answer. Hope to have a patch together soon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Handshaking on USB serial devices
Alan Cox wrote: >> byte of a packet is being thrown away about .1% of the time for the pl2303, >> but I'm not sure if the FTDI driver still suffers from a similar rash. I >> > > A 20 byte low speed message is too small for flow control to account for > it. I agree. I've observed the first byte of received data disappears on pl2303 devices, but haven't spent time finding out why. (It's on my list.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Feature Removals for 2.6.25
Arjan van de Ven wrote: > Bill Davidsen wrote: >> Note that because the hardware is old, it's highly likely that most >> of it will be retired before that sk98lin driver needs a change. I >> can't see anyone using sk98lin on a new system, so it would be less >> contentious to let the hardware (or users) die of natural causes if >> you can. >> > > the problem is that the new one DOES NOT GET FIXED. > THAT is a huge problem; it means we have a buggy driver... If the old one works and the new one is buggy, it begs the question of why anybody bothered writing a new one in the first place. "If it ain't broke, don't fix it," might have been good advice to follow. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Handshaking on USB serial devices
Alan Cox wrote:
>> To make it clear: Even aside from the buffer in 2.6's pl2303.c, there's
>> a race: An in-flight write URB can fill all hardware buffers, making
>> unsafe what previously appeared to be a safe write. I think it's
>> essential to delay submission of the URB on a stop-transmit condition.
>>
>
> Hardware flow control *is* a race, and always will be. The remote end has
> a delay in signalling 'stop' there is a propogation delay and a response
> delay. This is why most implementations assert stop a bit *before* they
> run out.
>
That's a very good point. Even so: on the 2.4 driver, write_room isn't
implemented (refer to a previous message by Alan); and in 2.6, a 1k
buffer is built into the driver, with nothing to prevent it being sent
when the hardware buffer fills. These could be bugs in the two versions
of pl2303, if you like; in fact I suppose they are; but there's a wider
problem: The same weakness can be found in aircable.c, airprime.c,
cyberjack.c, cypress_m8.c (I think), empeg.c, ftdi_sio (I think),
io_ti.c, and that's where I stop checking, and declare it's widespread.
> Given the size of transfers and the internal buffering one would hope the
> USB devices do their own flow control if told to properly.
>
RS232 is (normally) so much slower than USB that, on an extended
transmission, the buffer internal to the local hardware can fill well
before the remote device has demanded that transmission stop. In fact,
now that you've mentioned it, I can't see that anything to stop the
driver from overflowing the internal buffer, which is very perplexing.
Would that be right? That seems a pretty dramatic weakness; how do you
write a large report to a slow printer without losing data?
I'm beginning to realise that overflowing the internal buffer is the
greatest risk of data loss. Hardware flow control almost seems
serendipitous. It gives us a reason to stop submitting bulk writes.
This is the essence of the change that I looking at for pl2303.c.
(Patch relative to kernel 2.6.23.14.) Does it make sense?
--- pl2303.c2008-01-15 07:19:56.0 +1030
+++ pl2303.c.new2008-02-15 04:22:12.0 +1030
@@ -370,6 +370,18 @@
spin_lock_irqsave(>lock, flags);
+ /*
+* there's a limit to how much we can buffer, so don't accept data while
+* CTS or DSR are low. XXX I don't know what to do about XON/XOFF.
+*/
+ if ((priv->line_control | CONTROL_RTS && !(priv->line_status &
UART_CTS)) || \
+ (priv->line_control | CONTROL_DTR && !(priv->line_status &
UART_DSR))) {
+ /*
+ spin_unlock_irqrestore(>lock, flags);
+ dbg("%s: send paused by remote flow control", __FUNCTION__);
+ return;
+ }
+
if (priv->write_urb_in_use) {
spin_unlock_irqrestore(>lock, flags);
return;
@@ -957,6 +969,9 @@
pl2303_update_line_status(port, data, actual_length);
+ /* send any buffered data */
+ pl2303_send(port);
+
exit:
retval = usb_submit_urb(urb, GFP_ATOMIC);
if (retval)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Handshaking on USB serial devices
Greg KH wrote: > On Thu, Feb 14, 2008 at 01:15:37AM +1030, David Newall wrote: > >> Consider a USB-attached serial port that is set to do RTS/CTS (or >> DSR/DTR) handshaking: What stops the kernel sending more data to it when >> the remote end lowers CTS (or DTR)? >> > > The tty layer should look at the proper flags and not send data on to > the driver in this kind of instance. > > Is this not happening properly for you? If so, which USB serial driver? > It's not happening properly, for pl2303 (and, I admit it! on kernel 2.4.) I think there's a widespread problem (i.e. with other drivers.) None of the drivers that I've examined check CTS or DTR; or, if they do, I can't see where. Likewise, I can't see it being done in n_tty nor tty_io; not even in usbserial. The best answer I can see is write_room, but that doesn't seem quite right. It seems that data written (via *_write) will merrily be transmitted to the converter, even while the remote end is signalling to stop, even if local hardware buffers fill. I have a working solution for the 2.4 driver, but am looking towards something for 2.6 and beyond. The 2.4 solution is in two parts: first, implement a write_room function, which returns 0 when transmission is required to stop, which apparently gives a hint to the tty layer. (NB, doesn't help when using a different line discipline.) The second part is to return 0 (or maybe -EAGAIN?) in the write function when transmission is required to stop. This appears sound. (Note that the generic putchar does no error checking, and fails when the write URB is busy. That's a problem with a fairly obvious solution.) The current 2.6 driver maintains it's own buffer. I think that's a bad thing: usbserial already buffers writes, and the extra buffer copy seems unnecessary, however it does solve the putchar problem. Buffered (i.e. by the 2.6 series pl2303 driver) data is written as soon as practicable, regardless of CTS/DTR. The same general workaround, but placed in pl2303_send seems correct to me; that is, stop submitting write urbs when the remote end lowers CTS/DTR, and trigger the resume from the interrupt callback (specifically in update_line_status.) As I say, this appears to be a widespread problem. I've looked at a number of drivers and in none of them can I see anything to prevent transmission when the remote end demands a stop. I'm not sure that the tty layer, which I think I said attempts to address the problem, albeit it does a half-arsed job, is the right place to do hardware handshaking. Equally, I'm not sure that the wheel should be re-invented for every driver, but that might be unavoidable. To make it clear: Even aside from the buffer in 2.6's pl2303.c, there's a race: An in-flight write URB can fill all hardware buffers, making unsafe what previously appeared to be a safe write. I think it's essential to delay submission of the URB on a stop-transmit condition. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Handshaking on USB serial devices
Greg KH wrote: On Thu, Feb 14, 2008 at 01:15:37AM +1030, David Newall wrote: Consider a USB-attached serial port that is set to do RTS/CTS (or DSR/DTR) handshaking: What stops the kernel sending more data to it when the remote end lowers CTS (or DTR)? The tty layer should look at the proper flags and not send data on to the driver in this kind of instance. Is this not happening properly for you? If so, which USB serial driver? It's not happening properly, for pl2303 (and, I admit it! on kernel 2.4.) I think there's a widespread problem (i.e. with other drivers.) None of the drivers that I've examined check CTS or DTR; or, if they do, I can't see where. Likewise, I can't see it being done in n_tty nor tty_io; not even in usbserial. The best answer I can see is write_room, but that doesn't seem quite right. It seems that data written (via *_write) will merrily be transmitted to the converter, even while the remote end is signalling to stop, even if local hardware buffers fill. I have a working solution for the 2.4 driver, but am looking towards something for 2.6 and beyond. The 2.4 solution is in two parts: first, implement a write_room function, which returns 0 when transmission is required to stop, which apparently gives a hint to the tty layer. (NB, doesn't help when using a different line discipline.) The second part is to return 0 (or maybe -EAGAIN?) in the write function when transmission is required to stop. This appears sound. (Note that the generic putchar does no error checking, and fails when the write URB is busy. That's a problem with a fairly obvious solution.) The current 2.6 driver maintains it's own buffer. I think that's a bad thing: usbserial already buffers writes, and the extra buffer copy seems unnecessary, however it does solve the putchar problem. Buffered (i.e. by the 2.6 series pl2303 driver) data is written as soon as practicable, regardless of CTS/DTR. The same general workaround, but placed in pl2303_send seems correct to me; that is, stop submitting write urbs when the remote end lowers CTS/DTR, and trigger the resume from the interrupt callback (specifically in update_line_status.) As I say, this appears to be a widespread problem. I've looked at a number of drivers and in none of them can I see anything to prevent transmission when the remote end demands a stop. I'm not sure that the tty layer, which I think I said attempts to address the problem, albeit it does a half-arsed job, is the right place to do hardware handshaking. Equally, I'm not sure that the wheel should be re-invented for every driver, but that might be unavoidable. To make it clear: Even aside from the buffer in 2.6's pl2303.c, there's a race: An in-flight write URB can fill all hardware buffers, making unsafe what previously appeared to be a safe write. I think it's essential to delay submission of the URB on a stop-transmit condition. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Handshaking on USB serial devices
Alan Cox wrote:
To make it clear: Even aside from the buffer in 2.6's pl2303.c, there's
a race: An in-flight write URB can fill all hardware buffers, making
unsafe what previously appeared to be a safe write. I think it's
essential to delay submission of the URB on a stop-transmit condition.
Hardware flow control *is* a race, and always will be. The remote end has
a delay in signalling 'stop' there is a propogation delay and a response
delay. This is why most implementations assert stop a bit *before* they
run out.
That's a very good point. Even so: on the 2.4 driver, write_room isn't
implemented (refer to a previous message by Alan); and in 2.6, a 1k
buffer is built into the driver, with nothing to prevent it being sent
when the hardware buffer fills. These could be bugs in the two versions
of pl2303, if you like; in fact I suppose they are; but there's a wider
problem: The same weakness can be found in aircable.c, airprime.c,
cyberjack.c, cypress_m8.c (I think), empeg.c, ftdi_sio (I think),
io_ti.c, and that's where I stop checking, and declare it's widespread.
Given the size of transfers and the internal buffering one would hope the
USB devices do their own flow control if told to properly.
RS232 is (normally) so much slower than USB that, on an extended
transmission, the buffer internal to the local hardware can fill well
before the remote device has demanded that transmission stop. In fact,
now that you've mentioned it, I can't see that anything to stop the
driver from overflowing the internal buffer, which is very perplexing.
Would that be right? That seems a pretty dramatic weakness; how do you
write a large report to a slow printer without losing data?
I'm beginning to realise that overflowing the internal buffer is the
greatest risk of data loss. Hardware flow control almost seems
serendipitous. It gives us a reason to stop submitting bulk writes.
This is the essence of the change that I looking at for pl2303.c.
(Patch relative to kernel 2.6.23.14.) Does it make sense?
--- pl2303.c2008-01-15 07:19:56.0 +1030
+++ pl2303.c.new2008-02-15 04:22:12.0 +1030
@@ -370,6 +370,18 @@
spin_lock_irqsave(priv-lock, flags);
+ /*
+* there's a limit to how much we can buffer, so don't accept data while
+* CTS or DSR are low. XXX I don't know what to do about XON/XOFF.
+*/
+ if ((priv-line_control | CONTROL_RTS !(priv-line_status
UART_CTS)) || \
+ (priv-line_control | CONTROL_DTR !(priv-line_status
UART_DSR))) {
+ /*
+ spin_unlock_irqrestore(priv-lock, flags);
+ dbg(%s: send paused by remote flow control, __FUNCTION__);
+ return;
+ }
+
if (priv-write_urb_in_use) {
spin_unlock_irqrestore(priv-lock, flags);
return;
@@ -957,6 +969,9 @@
pl2303_update_line_status(port, data, actual_length);
+ /* send any buffered data */
+ pl2303_send(port);
+
exit:
retval = usb_submit_urb(urb, GFP_ATOMIC);
if (retval)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Feature Removals for 2.6.25
Arjan van de Ven wrote: Bill Davidsen wrote: Note that because the hardware is old, it's highly likely that most of it will be retired before that sk98lin driver needs a change. I can't see anyone using sk98lin on a new system, so it would be less contentious to let the hardware (or users) die of natural causes if you can. the problem is that the new one DOES NOT GET FIXED. THAT is a huge problem; it means we have a buggy driver... If the old one works and the new one is buggy, it begs the question of why anybody bothered writing a new one in the first place. If it ain't broke, don't fix it, might have been good advice to follow. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Handshaking on USB serial devices
Alan Cox wrote: byte of a packet is being thrown away about .1% of the time for the pl2303, but I'm not sure if the FTDI driver still suffers from a similar rash. I A 20 byte low speed message is too small for flow control to account for it. I agree. I've observed the first byte of received data disappears on pl2303 devices, but haven't spent time finding out why. (It's on my list.) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Handshaking on USB serial devices
Greg KH wrote: On Thu, Feb 14, 2008 at 07:55:44PM +1030, David Newall wrote: The current 2.6 driver maintains it's own buffer. I think that's a bad thing: usbserial already buffers writes, and the extra buffer copy seems unnecessary, however it does solve the putchar problem. Buffered (i.e. by the 2.6 series pl2303 driver) data is written as soon as practicable, regardless of CTS/DTR. The same general workaround, but placed in pl2303_send seems correct to me; that is, stop submitting write urbs when the remote end lowers CTS/DTR, and trigger the resume from the interrupt callback (specifically in update_line_status.) Where does the usbserial core buffer writes on 2.6? The serial_write() function just passes the data straight down to the usb-serial child driver directly, no copying or buffering happens that I can see. You're right. I haven't examined the 2.6 stack as closely as the 2.4. I noticed the buffer in 2.6 pl2303, but didn't check 2.6 usb-serial. I think I prefer the buffer in usb-serial, because its centralised rather than in each driver, but I'm not going to step up to the plate and propose changing that! To make it clear: Even aside from the buffer in 2.6's pl2303.c, there's a race: An in-flight write URB can fill all hardware buffers, making unsafe what previously appeared to be a safe write. I think it's essential to delay submission of the URB on a stop-transmit condition. It's up to the individual driver to know when their buffers are filled up. The big problem is, a lot of these cheap usb-serial devices (like the pl2303) don't have a way to report the uart queue filled-state back to the host, so things can easily get over-run as you have found out. My understanding of the problem has developed over the last couple of days; going from wrist-deep to elbow-deep into the guts of things does that. There is a problem, and the solution I've been developing addresses it, but maybe there's a simpler answer. Hope to have a patch together soon. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Handshaking on USB serial devices
Consider a USB-attached serial port that is set to do RTS/CTS (or DSR/DTR) handshaking: What stops the kernel sending more data to it when the remote end lowers CTS (or DTR)? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Handshaking on USB serial devices
Consider a USB-attached serial port that is set to do RTS/CTS (or DSR/DTR) handshaking: What stops the kernel sending more data to it when the remote end lowers CTS (or DTR)? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Greg KH wrote: > A "driver" is not an "application" as you tried to reference in your > prior quotes. I think your treating what the learned Professors said to literally. > It is a tiny portion of the whole kernel, The Copyright Act draws no such a distinction. > and as such, > does fall under the derivative works portion when it is run within the > Linux kernel. > Section 0 of GPL: The act of running the Program is not restricted. > Again, see the Samba decisions that have happened in the past when > companies have tried to add modules to it that are not under the GPL. > They have failed every single time, so there is a lot of precedent for > this kind of thing. > I'd like to, but I've searched and searched and can't find them. Some pointers, maybe a search term, would be useful. > This is going to be my last response on this thread, Good idea. I've spent too much time on this already, so I think I'll join you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
My, I am full of post scripts today. This one is a peace token for Alan. David Newall wrote: > there are more reliable and transparent sources [than Alan.] Don't take his > word on it. Take the words of real experts in the law, because instead > of a mere four word conclusion, they explain everything. I do realise that my later postings come across harshly for Alan, and that they might seem to be attacking him. Of course, he did set himself up for that with his own snide and personal attacks on me. However, I took no offense and likewise intended none. I have not intended anything personally. I'm sure he's a jolly reliable bloke, and I can see he's a hard worker for, and advocate of, Linux, and that he's enormously respected. Nobody is right all the time and this, I believe, is a case where he is wrong. I hope nobody is upset that I pointed it out. I also hope that the ideas behind EXPORT_SYMBOL_GPL might be reconsidered. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
I explained something poorly: > Now, Alan has made a big issue over numerous legal opinions he has > received, but he's been completely coy in the details. The point I wanted to make is that a few people have said that lawyers say that kernel modules are derivative, but I only remember Alan saying that he had actually spoken with the lawyers. Therefore I infer that this somewhat widely held opinion originates from him. My point was to those people who have been taking him at his word, and was to point out that there are more reliable and transparent sources. Don't take his word on it. Take the words of real experts in the law, because instead of a mere four word conclusion, they explain everything. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Marcel Holtmann wrote:
> Anyway you are still under the impression that a Linux kernel module can
> be original work in the end. We keep telling you that could be a wrong
> assumption which is based on the view of many of the kernel developers
> and of most of the lawyers that looked at this specific topic.
>
Yes, I am of that view. I accept that I could be wrong, but that also
means that I could be right. We agree, so far. The important point is
that I could be right. What will be done when somebody brings forth such
an work? Will the restriction in EXPORT_SYMBOL_GPL be removed, or will
the driver be unfairly restricted from using those other modules? You
did agree I could be right, so positing such a driver, what happens? (I
predict nothing; the driver is unfairly restricted.)
Now, Alexander Terekhov has forwarded some links to me, relating to the
question of whether or not a Linux kernel module can be original. Bear
in mind that these links relate to U.S. Copyright Law.
In http://digital-law-online.info/lpdi1.0/treatise27.html, Professor Lee
A Hollaar discusses derivative work and linking with libraries. He says:
Some have claimed that an application program that needs a library
for its operation is a derivative work of that library. They take
that position because the application program is "based on" the
library because it was written to use the subroutines and other
aspects of the library.
Such a position is misplaced. Even though the definition of a
derivative work contained in Section 101 seems to support such a
reading when it talks about a derivative work’s being "based upon
one or more preexisting works," the examples all illustrate
derivative works where the original work is somehow incorporated or
recast in the derivative work:
A "derivative work" is a work based upon one or more preexisting
works, such as a translation, musical arrangement, dramatization,
fictionalization, motion picture version, sound recording, art
reproduction, abridgment, condensation, or any other form in which a
work may be recast, transformed, or adapted. A work consisting of
editorial revisions, annotations, elaborations, or other
modifications which, as a whole, represent an original work of
authorship, is a "derivative work". {FN109: 17 U.S.C. §101
}
This need to use a portion of the original work in the derivative
work is stated in the legislative history of the Copyright Act of
1976, where the drafters discussed when the derivative work
exclusive right is infringed:
To be an infringement the "derivative work" must be "based upon the
copyrighted work," and the definition in section 101 refers to "a
translation, musical arrangement, dramatization, fictionalization,
motion picture version, sound recording, art reproduction,
abridgment, condensation, or any other form in which a work may be
recast, transformed, or adapted." Thus, to constitute a violation of
section 106(2), the infringing work must incorporate a portion of
the copyrighted work in some form;
Let me say it: A work that incorporates no portion of a copyrighted work
is not derivative. He goes on to say:
It could be argued that the component program really does include
portions of the library that it uses – data structures that are
passed as parameters, or even the parameter lists themselves. But
elements dictated by external considerations are filtered out when
trying to determine whether there is copyright infringement.
Elsewhere he says, by implication, that "elements like the overall
program structure or architecture and data structures that are ...
dictated by external or efficiency considerations" are not "protected by
the original program’s copyright".
He finishes this part of his treatise by saying:
No other conclusion makes sense. If it were not the case, then any
program using the applications program interfaces (APIs) of an
operating system could be considered a derivative work of that
operating system.
Another germane reference provided by Alexander
A lengthy article by Prof. Dr. Lothar Determann can be found at
http://www.usfca.edu/law/determann/softwarecombinations060403.pdf
(DANGEROUS LIAISONS – SOFTWARE COMBINATIONS AS DERIVATIVE WORKS?). In
the abstract, Prof. Dr. Determann writes:
The article concludes that most forms of software combinations are
less dangerous than commonly assumed, because they do not constitute
derivative works (but instead either compilations or sui generis
aggregations outside the scope of the copyright owner’s exclusive
rights), and a number of statutes and legal doctrines significantly
limit a copyright owner’s ability to contractually prohibit software
combinations that do not also constitute derivative works under
copyright law.
In the Introduction
Re: [PATCH] USB: mark USB drivers as being GPL only
Alan Cox wrote: > On Fri, 08 Feb 2008 13:25:33 +1030 > David Newall <[EMAIL PROTECTED]> wrote: > > >> Alan Cox wrote: >> >>>> It would not be improper to say that "such and such a lawyer said this >>>> and that." I'm not proposing that you breach their copyright in their >>>> >>>> >>> It would be highly improper given these were business discussions >>> involving companies using Linux. >>> >> Then you should never have brought it up. Since you never really said >> what any lawyer told you, let's just forget that you did bring it up. >> > > I thought you would care that lawyers had discussed the matter. I care, but I have no way of knowing what was advised. I bet you a dollar they never said that all kernel modules are derivative. You haven't said that they did, but the entire argument supporting, let me call it "pro-EXPORT_SYMBOL_GPL", is based on the concept that they did. > I hope it makes you very happy, welcome to > my killfile. Why would that bother me? You said it before, anyway. It was childish then, and is childish now. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Greg KH wrote: A driver is not an application as you tried to reference in your prior quotes. I think your treating what the learned Professors said to literally. It is a tiny portion of the whole kernel, The Copyright Act draws no such a distinction. and as such, does fall under the derivative works portion when it is run within the Linux kernel. Section 0 of GPL: The act of running the Program is not restricted. Again, see the Samba decisions that have happened in the past when companies have tried to add modules to it that are not under the GPL. They have failed every single time, so there is a lot of precedent for this kind of thing. I'd like to, but I've searched and searched and can't find them. Some pointers, maybe a search term, would be useful. This is going to be my last response on this thread, Good idea. I've spent too much time on this already, so I think I'll join you. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Marcel Holtmann wrote:
Anyway you are still under the impression that a Linux kernel module can
be original work in the end. We keep telling you that could be a wrong
assumption which is based on the view of many of the kernel developers
and of most of the lawyers that looked at this specific topic.
Yes, I am of that view. I accept that I could be wrong, but that also
means that I could be right. We agree, so far. The important point is
that I could be right. What will be done when somebody brings forth such
an work? Will the restriction in EXPORT_SYMBOL_GPL be removed, or will
the driver be unfairly restricted from using those other modules? You
did agree I could be right, so positing such a driver, what happens? (I
predict nothing; the driver is unfairly restricted.)
Now, Alexander Terekhov has forwarded some links to me, relating to the
question of whether or not a Linux kernel module can be original. Bear
in mind that these links relate to U.S. Copyright Law.
In http://digital-law-online.info/lpdi1.0/treatise27.html, Professor Lee
A Hollaar discusses derivative work and linking with libraries. He says:
Some have claimed that an application program that needs a library
for its operation is a derivative work of that library. They take
that position because the application program is based on the
library because it was written to use the subroutines and other
aspects of the library.
Such a position is misplaced. Even though the definition of a
derivative work contained in Section 101 seems to support such a
reading when it talks about a derivative work’s being based upon
one or more preexisting works, the examples all illustrate
derivative works where the original work is somehow incorporated or
recast in the derivative work:
A derivative work is a work based upon one or more preexisting
works, such as a translation, musical arrangement, dramatization,
fictionalization, motion picture version, sound recording, art
reproduction, abridgment, condensation, or any other form in which a
work may be recast, transformed, or adapted. A work consisting of
editorial revisions, annotations, elaborations, or other
modifications which, as a whole, represent an original work of
authorship, is a derivative work. {FN109: 17 U.S.C. §101
http://www4.law.cornell.edu/uscode/17/101.html}
This need to use a portion of the original work in the derivative
work is stated in the legislative history of the Copyright Act of
1976, where the drafters discussed when the derivative work
exclusive right is infringed:
To be an infringement the derivative work must be based upon the
copyrighted work, and the definition in section 101 refers to a
translation, musical arrangement, dramatization, fictionalization,
motion picture version, sound recording, art reproduction,
abridgment, condensation, or any other form in which a work may be
recast, transformed, or adapted. Thus, to constitute a violation of
section 106(2), the infringing work must incorporate a portion of
the copyrighted work in some form;
Let me say it: A work that incorporates no portion of a copyrighted work
is not derivative. He goes on to say:
It could be argued that the component program really does include
portions of the library that it uses – data structures that are
passed as parameters, or even the parameter lists themselves. But
elements dictated by external considerations are filtered out when
trying to determine whether there is copyright infringement.
Elsewhere he says, by implication, that elements like the overall
program structure or architecture and data structures that are ...
dictated by external or efficiency considerations are not protected by
the original program’s copyright.
He finishes this part of his treatise by saying:
No other conclusion makes sense. If it were not the case, then any
program using the applications program interfaces (APIs) of an
operating system could be considered a derivative work of that
operating system.
Another germane reference provided by Alexander
A lengthy article by Prof. Dr. Lothar Determann can be found at
http://www.usfca.edu/law/determann/softwarecombinations060403.pdf
(DANGEROUS LIAISONS – SOFTWARE COMBINATIONS AS DERIVATIVE WORKS?). In
the abstract, Prof. Dr. Determann writes:
The article concludes that most forms of software combinations are
less dangerous than commonly assumed, because they do not constitute
derivative works (but instead either compilations or sui generis
aggregations outside the scope of the copyright owner’s exclusive
rights), and a number of statutes and legal doctrines significantly
limit a copyright owner’s ability to contractually prohibit software
combinations that do not also constitute derivative works under
copyright law.
In the Introduction he says:
[C]ourts
Re: [PATCH] USB: mark USB drivers as being GPL only
I explained something poorly: Now, Alan has made a big issue over numerous legal opinions he has received, but he's been completely coy in the details. The point I wanted to make is that a few people have said that lawyers say that kernel modules are derivative, but I only remember Alan saying that he had actually spoken with the lawyers. Therefore I infer that this somewhat widely held opinion originates from him. My point was to those people who have been taking him at his word, and was to point out that there are more reliable and transparent sources. Don't take his word on it. Take the words of real experts in the law, because instead of a mere four word conclusion, they explain everything. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
My, I am full of post scripts today. This one is a peace token for Alan. David Newall wrote: there are more reliable and transparent sources [than Alan.] Don't take his word on it. Take the words of real experts in the law, because instead of a mere four word conclusion, they explain everything. I do realise that my later postings come across harshly for Alan, and that they might seem to be attacking him. Of course, he did set himself up for that with his own snide and personal attacks on me. However, I took no offense and likewise intended none. I have not intended anything personally. I'm sure he's a jolly reliable bloke, and I can see he's a hard worker for, and advocate of, Linux, and that he's enormously respected. Nobody is right all the time and this, I believe, is a case where he is wrong. I hope nobody is upset that I pointed it out. I also hope that the ideas behind EXPORT_SYMBOL_GPL might be reconsidered. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Alan Cox wrote: On Fri, 08 Feb 2008 13:25:33 +1030 David Newall [EMAIL PROTECTED] wrote: Alan Cox wrote: It would not be improper to say that such and such a lawyer said this and that. I'm not proposing that you breach their copyright in their It would be highly improper given these were business discussions involving companies using Linux. Then you should never have brought it up. Since you never really said what any lawyer told you, let's just forget that you did bring it up. I thought you would care that lawyers had discussed the matter. I care, but I have no way of knowing what was advised. I bet you a dollar they never said that all kernel modules are derivative. You haven't said that they did, but the entire argument supporting, let me call it pro-EXPORT_SYMBOL_GPL, is based on the concept that they did. I hope it makes you very happy, welcome to my killfile. Why would that bother me? You said it before, anyway. It was childish then, and is childish now. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Marcel Holtmann wrote: > Hi David, > > > I think you're missing my point: as long as the license stays the way > it is now, you can never distribute proprietary code unless you've > consulted a lawyer and even then you run the risk of being sued for > infringement if the copyright holder thinks what you have is derived > work. > > Yes I can, if the proprietary code is not linked with GPL code (and the proprietary code is original). Loadable modules are not linked. This is a very clear-cut case. >>> that is not clear-cut case. You link at run-time. Otherwise the module >>> would do nothing. >>> >> That's why it's allowed. The module isn't linked when it's distributed, >> and the author doesn't do or cause the linking; the user does. And the >> user never distributes in the linked state. Distribution is key to GPL. >> > > so how do you build this module that is not linked without using the > Linux kernel. You could hand code in assembler, using Microsoft's assembler under Windows. You could compile from C, using GCC on FreeBSD. But that's immaterial. A module which is an original, non-derivative work, is, well, original and non-derivative. Do you say that it must be otherwise? Why would that be? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Alan Cox wrote: >> It would not be improper to say that "such and such a lawyer said this >> and that." I'm not proposing that you breach their copyright in their >> > > It would be highly improper given these were business discussions > involving companies using Linux. Then you should never have brought it up. Since you never really said what any lawyer told you, let's just forget that you did bring it up. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Hans-Jürgen Koch wrote: > The license says that derivative work has to be GPL. Naturally, every > sensible and practically usable license has gray areas. We know that > and we live with that. But if there's room for interpretation, it's > perfectly OK and helpful, if the copyright holder states what his > interpretation is. If you use an EXPORT_SYMBOL_GPL symbol in non-GPL > code, you know that the owner of the work doesn't agree with you > license-wise. How can an author form the opinion that another work is derivative, when it hasn't even necessarily been written yet? EXPORT_SYMBOL_GPL is no statement of the author's beliefs. It's an algorithm of restriction, and it affects original, non-derivative works. >> It requires software that is *distributed* as part of a GPL >> work to itself be GPL. At time of distribution, a kernel module is >> neither using nor linked to the kernel. >> > > Oh, come on! You cannot turn a derived work into an original work just > by distributing them seperately. That's not what I said. From the start, I've made clear that I'm talking of original, non-derivative works. You said that mere linking makes that non-derivative work derivative: > Using a symbol from a library means linking to it, and that creates a > derived work. Why should it be different when using kernel symbols? This is wrong for the reasons I stated. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Hans-Jürgen Koch wrote: > Am Fri, 08 Feb 2008 01:01:24 +1030 > schrieb David Newall <[EMAIL PROTECTED]>: > >>> It is not legally meaningless if copyright holders publicly state >>> how they interpret the license and what they consider a license >>> violation. >>> >> Copyright-holders' opinions mean nothing. In the particular case of >> EXPORT_SYMBOL_GPL, copyright-holders' opinions are clearly flawed >> because they make a statement about code that they do not even know >> of. >> > > What are you talking about? That's what every GPL-licensed library > does. By putting a library under the GPL, the copyright-holder clearly > states that he considers all programs that link against that library a > derived work. And that he therefor requires these programs to be GPL, > too, no matter if these programs already exist or not. > Your last sentence, above: That is what EXPORT_SYMBOL_GPL attempts to do. The place to state such a requirement is in the licence, not in the source code. That is what I am talking about. I can't provide you with software under a licence that says, "you are free to use this software in any way you want," and later say, "oh, but in the source code is tells you that you must take a break every two hours of use." >> Less there be further confusion: I am not an advocate for binary >> drivers. >> > > Nice to hear. So, if you're an advocate for open source drivers, why do > you have problems making them GPL? > I don't, but EXPORT_SYMBOL_GPL doesn't do that. It makes an ambit claim, that might coerce an author into making a driver GPL, but might also cause them to exit the Linux market. I have a problem with driving manufacturers away from Linux. > Using a symbol from a library means linking to it, and that creates a > derived work. Why should it be different when using kernel symbols? I don't agree with your claim, but I'm going to explain something else: The GPL doesn't require software that *uses* GPL code to itself be GPL. It requires software that is *distributed* as part of a GPL work to itself be GPL. At time of distribution, a kernel module is neither using nor linked to the kernel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Alan Cox wrote:
>> previous statements which seemed to say, "you've spoken to numerous
>>
>
> Please don't use "seemed to say" and then quote words I've never said.
> That's misleading, rude and also awful language style.
No, it's called, "paraphrasing," and it's quite normal in a
conversation. You say something, I tell you what I think you said, you
refine your language, and the process continues until we're happy that a
semantic consensus has been reached. In that spirit, should I now
understand that what you meant is that *you* *think* that kernel modules
must be released under GPL. Should I accept that you didn't mean that
numerous lawyers had told you that this was factually so?
Of course, this begs the question of why there would be a
MODULE_LICENSE("proprietary"). You may hold beliefs as understood
above, but it seems guaranteed that the opinions of those who count are
divided.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Alan Cox wrote: >> No, I'm right. The word "proof" is appropriate in context. (I write in >> plain English, not Legalese.) I certainly didn't intend "proof" to mean >> "mathematically certain." Anybody who pretends that proof in court >> means that must be ignorant or trying to deceive. >> > > I'm afraid you are wrong despite your desperate attempts to reinterpret > your own comments. The civil law is "balance of probability". Those are > the precise words used. As it is a dispute between two civil parties with > no assumed right or wrong it is a matter of which interpretation is most > likely "proof" doesn't come into it whatever version of proof you want to > pick this email. > > "burden of proof" is a specific term with a specific meaning in law. > I've had this argument before. The conclusion is that spiteful people insist on using the legal meaning for words which have explicitly been said using plain English. If you are spiteful, then by all means rant about legal terms, but do so knowing that everybody understand what I mean. Even in civil matters, it is necessary for the appellant to present a case and the respondent may simply pick holes in it. Further, don't forget that copyright violation is a criminal matter in some jurisdictions. I it is so in Australia, and attracts penalties that include imprisonment. In Australia, and I wonder if it isn't so in USA, the legal interpretation that you so keenly insist upon, must therefore apply. I shall not engage in further debate about what the legal meaning is of plain English terms. It's a stupid argument suitable only for stupid people. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Alan Cox wrote: >> That's what you claim it says, but has any court, anywhere, agreed with >> you? You claim the authority of others (i.e. numerous lawyers), but I >> don't believe you have that authority. You're just starting hearsay. >> You've never said what lawyers and you've never told us what they >> actually said. >> > > That would be improper as you'd well know if you knew the first thing > about the subject. > It would not be improper to say that "such and such a lawyer said this and that." I'm not proposing that you breach their copyright in their opinions, but there is such a thing as fair use, and I expect you to use it or stop bringing it up. Anything less than that starts to sound odd. >> I see that you have a clear political agenda, and I respect it in >> principle, but you're claiming that things are so in pursuit of that >> agenda when you don't *know* that they are. You don't need to stretch >> any truths to spread adoption of GPL, and doing so is not respectable. >> > > Why don't you just say "you are a liar" as I assume that is what you want > to say. Various reasons. I don't know that you're a liar and I'm too much the gentleman to accuse you of that without being quite sure of my facts. As it happens I assume you're not lying, but I do suspect you of having misrepresented what was said to you. I don't say you've done this out of malice; it's possible you've read things into opinions given to you that weren't meant; or even inaccurately remembered what was said. Mostly, I think what I've already said: In other words, I think you've put a spin on the opinions in pursuit of your own agenda. You've already watered down your claims, being that you now say, "bad idea". >> I don't understand this, but I do understand that an essential question >> being considered is whether or not Linux can participate in a market >> that prohibits GPL drivers, whether explicitly, or more likely through >> pressure from regulatory bodies. Doing this would be a mistake. >> Probably a big one. >> > > Linux is GPL licencesed code you either follow the licence or don't use > it. It's very simple. > Okay, that I understand. That is simple. But it's irrelevant to the topic under discussion, which is to seek to restrict access to modules based on their specific licence conditions. The GPL makes no such restriction, and it is improper and legally meaningless, from a licence point of view, to claim that EXPORT_SYMBOL_GPL forms a condition of licence. It doesn't. (There may be DMCA considerations, but I hope that everyone from Stallman to Torvalds would hasten to disclaim them.) >> Don't telling people to switch to BSD, as some have done; they might do >> it. Where would Linux be if embedded devices used BSD instead? Don't >> > > I don't actually care. If you want to do binary products then pick a > product you have the right to do that with. > Please don't refer to me in this way. Say, rather, "if someone wants to do binary products." Putting that aside, Linux is such a product. There is nothing in the GPL that suggests it may not be used with proprietary products, and much to say that it may. >> think they can't. Don't think Linux has a technical advantage. Lose >> the embedded market, and that's where it would be felt first, and Linux >> volumes fall by what? 50%? 90%? Would you care if servers followed? >> > > The market will ultimately decide which models of software development > are the right ones for which situation. > Presumably you mean "product," and not "model of software development," since later in no way relates to the topic. The market will ultimately decide which product is right. It would be a great shame if Linux dwindled. There's no shortage of fully open source operating systems, but the one enjoying success which requires source to be distributed with (hardware) product is Linux. I don't want that to change. I make purchasing decisions for clients based on availability of source. BSD isn't useful. Annex used BSD (there was no GPL) and their product was poorer for it. I don't particularly like binary drivers, but I like binary-only operating systems even less. There's no need to play brinksmanship with manufacturers. Please don't take Linux away from my router, and my modem, and my access point, and my telephone, and my printer. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Alan Cox wrote: >> It's nonsense, it's a reasonable reading of the GPL. What I am doing is >> telling you what the GPL says, not what you wish it said. >> > > In which case for each statement please give the case at appeal or higher > level which is the precedent for the interpretation. > I am giving my opinion. By contrast, you have claimed to be giving the opinion of numerous lawyers. I hate to be so blunt, but that is the naked truth. You could improve that situation. >>> If the developers say that this symbol can only be used in GPL code (and >>> with EXPORT_SYMBOL_GPL it is quite clear) then you have to obey to that >>> license or don't use this symbol at all. >>> >>> >> EXPORT_SYMBOL_GPL is not a licence. Only a licence is a licence. >> > > Export symbol is a guide. There is no reason to think that EXPORT_SYMBOL > symbols alone mean your work is somehow not derivative. No argument, other than with, "export symbol is a guide." My argument with that is that one could mistakenly infer that "export symbol" includes "EXPORT_SYMBOL_GPL." The latter is not a guide, is it? It restricts a symbol from use by proprietary modules. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Alan Cox wrote: >> Again, I missed who wrote the above. I'm reminded of Apple computer, >> who explaining some engineering decisions in the Apple ][ pointed out >> that an additional 10c in components adds $10 to the retail price (or >> something rather like that.) Cheap, cheap, cheap helps market share >> far more than quality. >> > > That depends on the market. Also the software cost is dominant not the > hardware cost so saving 10c on licensing by not using Windows kind of > wipes out any questions. Software cost is fixed, whereas hardware is per-unit, so saving 10c in production at an expense of $1,000,000 in development can be an easy win. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Diego Zuccato wrote: > David Newall ha scritto: > >> That's naive, since requirements differ in different jurisdictions, as >> I'm sure you are perfectly aware. > Naive? Who thinks a limit can be enforced by sw is naive! Of course. Naturally it's near impossible to prevent people from tweaking the software. But reasonable restrictions are what regulatory bodies expect. > Precisely: One purpose of the driver is to enforce local compliance. > It can't *enforce* it anyway, at least if the users are all around the > world. Yes it can. You're confusing the software with different or modified software. Different things. And by the way, if you modify the software to defeat the restrictions you are committing a criminal act, or you would be if you did it in Australia. You'd probably get with crucifixion for a first offense! >>> But linear amplifiers are commonly sold. And (at least in Italy) it's >>> not illegal to buy one, even if it can boost antenna power to 1000W. >>> It's illegal just to USE it. >> In Australia it's illegal to own them (CB licensee; HAMs are allowed to >> use them, although not on 27Mhz.) > Then Australian shops can ask for the licence. And what about online > shops? Ebay? They'll send you an unmarked package (same as letting you > download another country's driver). The result is that you can have > your LA more easyly than going to a local shop or tampering with your > CB (or tampering whith the local version of the driver). What's your point? That it's easy to break the law? Nobody's arguing against that. >>> And it's a logical problem, too: why should the *driver* enforce a >>> *technical* limit? >> That's part of it's purpose. It permits a manufacturer to make a global >> device that operates within local restrictions. > Nope. The driver should simply make the device WORK. The USER must > make sure to meet the local regulations. Definitely no. The manufacturer must ensure it meets local regulations. One way they do that is via the driver. > The driver can help, but as long as it asks the user a country > setting, its enforcement is nearly nothing! You're correct, but that's still how it is. In fact, some manufacturers provide country specific drivers simply to shore up this weakness. (They'd only do that to protect their regulatory approval.) > Another example. Think about what happens if you're right: the user > gets caught with a WiFi card operating on an illegal channel, but the > system appears correctly configured (location-wise). When analyzed, it > turns out that, due to a bug in the driver, the card uses that channel > (for example 13) because the user only changed the country setting > when flying back from Japan (where he used channel 13) and channel > limiter didn't kick in. Is the manufacturer responsible? Are you asking if the manufacturer could lose their licence to sell the product? It could happen. Regulators do wield significant powers. > If you're right, he is and must pay, remove that device from shops and > replace sold ones. Or at least make sure all users update their > drivers with others without that bug... That's the most likely result. That would be what I expect would happen. This is why manufacturers view open source licences dimly in certain markets, of which radio communications is just one example. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Alan Cox wrote: >>> IANAL, but when looking at the "But when you distribute the same >>> sections as part of a whole which is a work based on the Program, the >>> distribution of the whole must be on the terms of this License" of the >>> GPLv2 I would still consult a lawyer before e.g. selling a laptop with a >>> closed-source driver loaded through ndiswrapper. >>> >> Don't ignore, "mere aggregation of another work not based on the Program >> with the Program (or with a work based on the Program) on a volume of a >> storage or distribution medium does not bring the other work under the >> scope of this License." Static linking certainly makes something part >> of the whole; dynamic linking doesn't. >> > > Wrong again. You really are quite amusing. I'm glad to entertain. It's a pity you refuse to be educated. Closed mind on the topic, perhaps? > The test is "derivative works" not linking. That is one of the terms used. Another, which I pointed out to your apparent glee, is "aggregation." Both terms are relevant only because they were chosen for use in GPL. > Linking is a meaningless (in law) computing term with no > place. Legal precedent for combining of works is drawn from things like > shipping a book and a commentary on the book together, putting music to > films, putting photos in a book. These are not "linking" > Whatever the precedent is, and I'll take your word on it even though it's more hearsay, it's explicitly covered by that part of the licence referring to "mere aggregation." > And I know what the lawyers I've talked to have said about the case of > shipping proprietary modules with the OS. Its a pretty definite "bad idea" Now, that's more like it. It sounds somewhat believable, unlike your previous statements which seemed to say, "you've spoken to numerous lawyers and they've all said that proprietary modules violate GPL." I paraphrased you, and if that's not what you meant then please take the opportunity to refine your claims. "Bad idea" is legal speak for, "I'll fight it for you, but you can lose." That's a big step away from "dynamic modules must be governed by GPL." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Alan Cox wrote: >> No. Holders of Linux copyrights would have to prove that the >> proprietary code is derived from the kernel. They have the burden of >> proof, and defence needs merely show that their arguments are wrong. >> > > Wrong again. In civil law in the USA and most of europe the test is > "balance of probability". > No, I'm right. The word "proof" is appropriate in context. (I write in plain English, not Legalese.) I certainly didn't intend "proof" to mean "mathematically certain." Anybody who pretends that proof in court means that must be ignorant or trying to deceive. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Alan Cox wrote: >> In Australia, devices require approval from a regulatory body. Such >> approval is withheld if appropriate safeguards are not applied. >> > > We were talking about the USA. We most certainly were not. We are talking about Linux, and everybody wants it be used globally. > I am not aware of any Australian answers > to the specific question of software as an appropriate safeguard. The US > requires appropriate safeguards but no court has actually established an > interpretation of them. > Probably the same in Australia, for the same reason as in USA. Probably the same in most countries. >> That is what I was saying: To require that only GPL-licenced USB drivers >> may be used with Linux puts Linux at a disadvantage in the market. The >> > > Diddums, thats what the license says. That's what you claim it says, but has any court, anywhere, agreed with you? You claim the authority of others (i.e. numerous lawyers), but I don't believe you have that authority. You're just starting hearsay. You've never said what lawyers and you've never told us what they actually said. I see that you have a clear political agenda, and I respect it in principle, but you're claiming that things are so in pursuit of that agenda when you don't *know* that they are. You don't need to stretch any truths to spread adoption of GPL, and doing so is not respectable. > Requiring ac cinema pays the movie > company puts a cinema at a disadvantage in the market from those who > don't pay. That is why we have laws to try and ensure that crime is not > profitable. I don't understand this, but I do understand that an essential question being considered is whether or not Linux can participate in a market that prohibits GPL drivers, whether explicitly, or more likely through pressure from regulatory bodies. Doing this would be a mistake. Probably a big one. Don't telling people to switch to BSD, as some have done; they might do it. Where would Linux be if embedded devices used BSD instead? Don't think they can't. Don't think Linux has a technical advantage. Lose the embedded market, and that's where it would be felt first, and Linux volumes fall by what? 50%? 90%? Would you care if servers followed? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Alan Cox wrote: >> The contract (GPL) doesn't prevent me from using GPL work, in fact it >> encourages me. Neither can it impose conditions upon original work >> authored by a third party. >> > > First mistake: The GPL is not a contract it is a license. Mea culpa. It is indeed a licence, which I did and do know. I really did mean, "The licence (GPL)" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Hans-Jürgen Koch wrote: > Am Thu, 07 Feb 2008 23:49:42 +1030 > schrieb David Newall <[EMAIL PROTECTED]>: > >> Nobody is saying "I don't like your licence." The issue is a >> technical restriction in Linux that attempts to restrict non-GPL >> software from running under it. >> > > What are you trying to say? You like the license but you're against > enforcing it? > I told you: the GPL does not preclude inter-operation with non-GPL software. >> It's a bullish approach, technically incompetent, >> > > What's incompetent? > It's easily defeated. >> legally meaningless >> > > It is not legally meaningless if copyright holders publicly state how > they interpret the license and what they consider a license violation. > Copyright-holders' opinions mean nothing. In the particular case of EXPORT_SYMBOL_GPL, copyright-holders' opinions are clearly flawed because they make a statement about code that they do not even know of. It's equivalent to someone saying, "you are wrong," before you've even thought about saying something. > In the end, a court must decide, but lots of courts will at least look > at the statements the copyright holders made over the years. > > >> and politically damaging. >> > > That's your opinion because it's damaging _your_ political goals. > How ludicrous. That's as much a nonsense as EXPORT_SYMBOL_GPL. You have no idea what my political goals are. Less there be further confusion: I am not an advocate for binary drivers. That role is reserved for others. However that does not stop me from criticising something that is obviously wrong. Stating that only a GPL code is permitted to use a symbol contravenes the GPL, because the GPL states no such requirement. Saying that it's impossible for code that uses the symbol to be non-GPL (as has been claimed) is a lie at worst, and a hope at best. Nobody claiming such a thing could know it to be true. (It is not true.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Alan Cox wrote: >> I heard this all before and I don't buy it anymore. At some point the >> companies in Asia will understand that the whole picture looks different >> and that not always cheap, cheap, cheap is best for their margins. Again, I missed who wrote the above. I'm reminded of Apple computer, who explaining some engineering decisions in the Apple ][ pointed out that an additional 10c in components adds $10 to the retail price (or something rather like that.) Cheap, cheap, cheap helps market share far more than quality. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Marcel Holtmann wrote: >>> if a new drivers is originally written for Linux, then you are breaking >>> the GPL. >>> >> Completely wrong. However if the driver is distributed as built-in, then it >> would need to be licensed under GPL. This means that a driver can be >> written and distributed as a module under any licence, proprietary or >> otherwise, presumably with the restriction that it may NOT be built-in. >> > > how to do you wanna write a new original Linux driver (modular or > built-in) without creating derivative work. >From what does it derive? Given a new, original work, created from scratch, could you point to another work, better yet show lines of code in common? >>> You driver was meant to be >>> running as Linux kernel module and thus it is derivative work. >>> >> It is precisely the fact that it is a loadable module, and does not form >> part of the kernel, that removes the requirement to distribute it under GPL. >> > > That is such a nonsense. Stop distributing FUD and start talking to a > lawyer. You are clearly under some weird impression what the GPL means > and what it implies. > It's nonsense, it's a reasonable reading of the GPL. What I am doing is telling you what the GPL says, not what you wish it said. > If the developers say that this symbol can only be used in GPL code (and > with EXPORT_SYMBOL_GPL it is quite clear) then you have to obey to that > license or don't use this symbol at all. > EXPORT_SYMBOL_GPL is not a licence. Only a licence is a licence. > If you use that symbol inside non-GPL (meaning you link at runtime) then > you are in violation of the GPL license. We can't make it much clearer. > Your desire is clear, but the facts are bound to disappoint you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Marcel Holtmann wrote: > Hi David, > > >>> I think you're missing my point: as long as the license stays the way >>> it is now, you can never distribute proprietary code unless you've >>> consulted a lawyer and even then you run the risk of being sued for >>> infringement if the copyright holder thinks what you have is derived >>> work. >>> >> Yes I can, if the proprietary code is not linked with GPL code (and the >> proprietary code is original). Loadable modules are not linked. This is a >> very clear-cut case. >> > > that is not clear-cut case. You link at run-time. Otherwise the module > would do nothing. That's why it's allowed. The module isn't linked when it's distributed, and the author doesn't do or cause the linking; the user does. And the user never distributes in the linked state. Distribution is key to GPL. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Greg KH wrote: > On Tue, Feb 05, 2008 at 10:09:07PM +1030, David Newall wrote: > >> Marcel Holtmann writes: >> >>> if a new drivers is originally written for Linux, then you are breaking >>> the GPL. >>> >> Completely wrong. However if the driver is distributed as built-in, then >> it would need to be licensed under GPL. This means that a driver can be >> written and distributed as a module under any licence, proprietary or >> otherwise, presumably with the restriction that it may NOT be built-in. >> > > Again, you are wrong, as per the recommendations of every lawyer I have > ever talked to (and unfortunatly, that's a lot...) > These words carry little weight as they are hearsay. You say that somebody told you something, but you don't who and you don't say precisely what, and on that basis you claim a conclusion. What you surely mean is that it's your opinion that I'm wrong, based on your interpretation of recommendations by lawyers. And since when did a lawyer ever give their opinion unequivocally? In my experience they always mince their words, providing no bankable guarantee. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Chris Friesen wrote: > Marcel Holtmann wrote: > >> If the developers say that this symbol can only be used in GPL code (and >> with EXPORT_SYMBOL_GPL it is quite clear) then you have to obey to that >> license or don't use this symbol at all. >> >> If you use that symbol inside non-GPL (meaning you link at runtime) then >> you are in violation of the GPL license. We can't make it much clearer. > > Not necessarily so. The developers feel that any code using that > symbol is necessarily a derivative work, The problem with that is this: To be derivative, a work has to be derived from another work. That's what "derivative" means. Is it by prescience that those marking symbols as EXPORT_SYMBOL_GPL know that only things derived from something else are capable of using them? Derived from what? The use of a separate module does not make something derivative. It makes it a client. Any binding between the two modules occurs only at runtime, and is purely ephemeral. I make this charge: Some, perhaps much, of the GPL-exported symbols have been mislabelled. There is no prescience, and those who labelled them such are really trying (and failing) to claim an additional licence condition. I further make this claim: an attempt to add a licence condition in that fashion is illegal, at least it is under various Australian laws, but I expect it's a similar story elsewhere. For a start, it's an attempt to vary licence conditions after the contract is made, and also without due notice. It also attempts to unfairly restrict trade. It's probably fraud, in that it purports to be a work provided under GPL, while silently claiming a different (and largely unstated) licence. The EXPORT_SYMBOL_GPL should be removed, because it's based on a lie. You cannot know that only GPL works are capable of using the symbol; you cannot know that all works that do use it are derivative of something; you cannot even say, a priori, what they are derived from. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Diego Zuccato wrote: > David Newall ha scritto: > >> "Of course", because in many parts of the world, a device who's >> manufacturer fails to take reasonable steps to prevent it from being >> used outside regulatory limits is illegal. Providing source code not >> only is a failure to take those reasonable steps, but is quite the >> opposite. It may even be viewed as encouraging users to use it >> inappropriately. > If the device is well engineered, there's nothing the sw can do to > make it work outside regulatory limits. That's naive, since requirements differ in different jurisdictions, as I'm sure you are perfectly aware. > Sometimes there's simply NOTHING the SW can do to *avoid* it. Think > about a CB radio. International standard is 5W (well, somewhere it's > 3, IIRC, but that's another story: nobody produces a special model > with a final amplifier for only 3W, everyone produces the 5W and turns > down power in some other way). Precisely: One purpose of the driver is to enforce local compliance. > But linear amplifiers are commonly sold. And (at least in Italy) it's > not illegal to buy one, even if it can boost antenna power to 1000W. > It's illegal just to USE it. In Australia it's illegal to own them (CB licensee; HAMs are allowed to use them, although not on 27Mhz.) > And it's a logical problem, too: why should the *driver* enforce a > *technical* limit? That's part of it's purpose. It permits a manufacturer to make a global device that operates within local restrictions. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Pekka Enberg wrote: > I have simply stated that (1) the problem boils down to what is > derived work and what is no and (2) the developers use the > EXPORT_SYMBOL_GPL as a hint of what they think to be derived work (not > necessarily tested in court). The _logical conclusion_ of these two > simple facts is, of course, to _not use_ functions marked as > EXPORT_SYMBOL_GPL unless you're willing to test your belief in court. > > Now I see you really want to argue about this but could you please do > it on some other list than the LKML? We use this list for real work > too, you know, and right now you're only contributing noise. Thanks! This *is* real work. You have blinded yourself to the fact that this discussion is preliminary to a proposed change. Or put another way, if you want to kill the discussion then the answer to "shall we" is "no." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Adrian Bunk wrote: > On Tue, Feb 05, 2008 at 05:34:23PM -0600, Chris Friesen wrote: > >> David Newall wrote: >> >>> That being said, a module can be written such that it only dynamically >>> links with the kernel. Ndiswrapper is an example of how this can be >>> done: None of the drivers that work under ndiswrapper make any direct >>> use of the kernel, not in any way, indeed a wrapper could be written >>> for a different operating system. >>> >> The issue is all about "derivative works" in copyright law. >> >> Ndiswrapper is in a good position because the closed-source drivers were >> originally written for another OS so it's pretty well impossible to >> argue that they are derived from linux. >> ... >> > > IANAL, but when looking at the "But when you distribute the same > sections as part of a whole which is a work based on the Program, the > distribution of the whole must be on the terms of this License" of the > GPLv2 I would still consult a lawyer before e.g. selling a laptop with a > closed-source driver loaded through ndiswrapper. > Don't ignore, "mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License." Static linking certainly makes something part of the whole; dynamic linking doesn't. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Marcel Holtmann wrote: > I disagree here. They either play by the roles or they really do pay > Microsoft or go with BSD. I really couldn't care less. Then you should keep away from the kernel. The last thing that Linux needs is someone who doesn't care if Linux succeeds or fails. "I don't care" will lead to failure. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Hans-Jürgen Koch wrote: > If somebody prefers an other OS for license reasons only, let them. You > cannot have open source software without open source license. If a > company chooses Linux, they do it for technical reasons, and because > they're able to modify the sources to suit their needs. Whatever > advantages they see in Linux, they have to know that they have to > accept its license. Just saying "I like your software but > your license is stupid" is childish. Use CE instead. Nobody is saying "I don't like your licence." The issue is a technical restriction in Linux that attempts to restrict non-GPL software from running under it. It's a bullish approach, technically incompetent, legally meaningless and politically damaging. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Christer Weinigel wrote: > I also think that my customers, that decided to keep their kernel > modules binary only, made a big mistake and have told them so. But I > still think it's better for the Linux community to be a bit soft on > such companies for a while. It's better to let them get away with it > for a while, and slowly try to convince them about the error of their > ways, rather than see them go with Windows CE or a BSD. > This nicely expresses my position. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Greg KH wrote: > On Wed, Feb 06, 2008 at 09:14:48PM +0100, Christer Weinigel wrote: > >> On Tue, 5 Feb 2008 12:34:18 -0800 >> Greg KH <[EMAIL PROTECTED]> wrote: >> >> >>> In the end, it's up to the copyright holders to enforce the license. >>> And as I have stated in the past, a number of them have made public >>> statements as to what they think about this issue. And it corresponds >>> exactly with what Marcel has stated above. >>> >>> So if you wish to violate the copyright of others, you take the risk >>> that you might be caught and punished, something that you and your >>> legal council needs to take into account. >>> >> So when do you sue Nvidia, ATI, Atheros, Broadcom[1], >> M-Systems/Sandisk[2] or Nokia? All those companies distribute binary >> drivers for Linux without providing source code? >> > > How do you know that such legal action isn't already happening? Is it? Or are you falsely implying that it is? I hope it is; that will help add fact to an otherwise opinion-ridden topic. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Chris Friesen wrote: > if I were to write a new GPL shim and then a new closed-source module > that uses the shim to access kernel symbols, it is entirely possible > that a court could rule that my closed-source module is a derivative > work of the linux kernel because it was written specifically to run on > linux. A lot of software is written specifically to run on Linux, but that doesn't mean it's derived from Linux. In the case of user-space code it's widely understood that no licence restrictions are conferred. The argument relating to kernel modules is that a module is somehow different because it runs in kernel mode. I can't see it, and in view of the status of user-space code, strong arguments would have to be made. > > On the other hand if I were to sit down and write an OS-agnostic > proprietary chunk of code, and then write a new GPL shim to use it > under linux (and maybe other shim layers for other OS's as well), I > _might_ be okay. But I would have to be prepared to prove that the > proprietary code was not derived from the Linux kernel. No. Holders of Linux copyrights would have to prove that the proprietary code is derived from the kernel. They have the burden of proof, and defence needs merely show that their arguments are wrong. (So if the proof is faulty, the case fails even if the code is derivative.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Alan Cox wrote: >> "Of course", because in many parts of the world, a device who's manufacturer >> fails to take reasonable steps to prevent it from being used outside >> regulatory limits is illegal. Providing source code not only is a failure >> to take those reasonable steps, but is quite the opposite. It may even be >> viewed as encouraging users to use it inappropriately. >> > > To my knowledge there is no caselaw on this for software, In Australia, devices require approval from a regulatory body. Such approval is withheld if appropriate safeguards are not applied. > nor is it > clearly so simple - many vendors do provide source, many vendors provide > windows drivers where any end user can click to specify their country and > can lie trivially. Many users retrofit US firmware to non US devices and > its trivial to do. Its a hard problem Yes it is; but what is simple, is to understand that lack of such safeguards, even though they are imperfect, does result in refusal to approve. > Some (particularly US) companies choose to take a conservative view based > Also, particularly Australia and New Zealand. I can't imagine France or Germany would be different. Where is it different? > on their pessimistic reading of the intent of the US regulator plus the > ability of the regulator to do a lot of damage to their business. > > The notion they are illegal is a real unknown and the market seems split > on views of this. > That is what I was saying: To require that only GPL-licenced USB drivers may be used with Linux puts Linux at a disadvantage in the market. The embedded market is simply huge. Microsoft would _love_ Linux to fail there, because that's what's necessary for Wince to win. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Greg KH wrote: > On Wed, Feb 06, 2008 at 09:44:36AM +1030, David Newall wrote: > >> A kernel module is akin to a process. It uses services of the kernel >> without being part of the kernel. >> > > No Linux does not work like this at all. > ... > Also see the various issues surrounding "loadable modules" and Samba, > and how they have successfully enforced the "linking" and other type > issues that are being discussed here (shims, "GPL condoms", etc.) with > regards to the GPLv2 and derivative works. If you know of something relevant, give pointers. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Alan Cox wrote: >> If we're still talking about whether a kernel module is required to be >> released under GPL, then yes, this is not a gray area. This is something >> that authors of original works can decide for themselves. They have no >> ^^^ > > Only if they are original works. > Yes. That was stipulated. > >> obligation to release under GPL, however they must take special care to >> ensure that the module does not (statically) link with the kernel. Richard >> > > Also wrong. > > You really should investigate a beginners text on intellectual property > law. Perhaps you might read up on unfair trade practices and contract law. The contract (GPL) doesn't prevent me from using GPL work, in fact it encourages me. Neither can it impose conditions upon original work authored by a third party. You do realise, I suppose, that it's easily feasible to write a Linux kernel module on a non-Linux platform, and in fact without even using any GPL software in its production. How could such a work possibly be derivative? How could it be affected by GPL? And please, don't give wishy-washy "lawyers tell me it's so" non-answers. Give something real. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Marcel Holtmann wrote: >>> If the developers say that this symbol can only be used in GPL code (and >>> with EXPORT_SYMBOL_GPL it is quite clear) then you have to obey to that >>> license or don't use this symbol at all. >>> Not sure who wrote the above, but it contains a glaring legal error: Developers choose an invalid forum to impose licence conditions when they choose to do so via EXPORT_SYMBOL_GPL. The licence that prevails is GPL, and nowhere does it say that protected works may only be used by other GPL works. In fact, such a notion is alien to the GPL. >>> If you use that symbol inside non-GPL (meaning you link at runtime) then >>> you are in violation of the GPL license. We can't make it much clearer. >>> >> Not necessarily so. The developers feel that any code using that symbol >> is necessarily a derivative work, but at the end of the day it would be >> up to the legal system to decide whether it really is or not. >> Of course courts are the proper forum to decide "fact" from opinion, but a statement of claim, which is a necessary preliminary to such an action, must state from what the alleged offending work is derived. The fact that claim of violation is made before any violating work has been identified, or even created, does work against such an action. A half-decent lawyer should be able to have any such action dismissed on that basis alone. I wonder if it isn't fraud to offer a work under the GPL and then to try to impose new conditions. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Marcel Holtmann wrote: If the developers say that this symbol can only be used in GPL code (and with EXPORT_SYMBOL_GPL it is quite clear) then you have to obey to that license or don't use this symbol at all. Not sure who wrote the above, but it contains a glaring legal error: Developers choose an invalid forum to impose licence conditions when they choose to do so via EXPORT_SYMBOL_GPL. The licence that prevails is GPL, and nowhere does it say that protected works may only be used by other GPL works. In fact, such a notion is alien to the GPL. If you use that symbol inside non-GPL (meaning you link at runtime) then you are in violation of the GPL license. We can't make it much clearer. Not necessarily so. The developers feel that any code using that symbol is necessarily a derivative work, but at the end of the day it would be up to the legal system to decide whether it really is or not. Of course courts are the proper forum to decide fact from opinion, but a statement of claim, which is a necessary preliminary to such an action, must state from what the alleged offending work is derived. The fact that claim of violation is made before any violating work has been identified, or even created, does work against such an action. A half-decent lawyer should be able to have any such action dismissed on that basis alone. I wonder if it isn't fraud to offer a work under the GPL and then to try to impose new conditions. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Alan Cox wrote: If we're still talking about whether a kernel module is required to be released under GPL, then yes, this is not a gray area. This is something that authors of original works can decide for themselves. They have no ^^^ Only if they are original works. Yes. That was stipulated. obligation to release under GPL, however they must take special care to ensure that the module does not (statically) link with the kernel. Richard Also wrong. You really should investigate a beginners text on intellectual property law. Perhaps you might read up on unfair trade practices and contract law. The contract (GPL) doesn't prevent me from using GPL work, in fact it encourages me. Neither can it impose conditions upon original work authored by a third party. You do realise, I suppose, that it's easily feasible to write a Linux kernel module on a non-Linux platform, and in fact without even using any GPL software in its production. How could such a work possibly be derivative? How could it be affected by GPL? And please, don't give wishy-washy lawyers tell me it's so non-answers. Give something real. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
