headers
Hubertus Franke | 1 Feb 2006 01:01
Picon
Favicon

Re: RFC [patch 13/34] PID Virtualization Define new task_pid api

Linus Torvalds wrote:
> (I'm coming in late, it's not been a high priority for me)
> 
> On Fri, 20 Jan 2006, Hubertus Franke wrote:
> 
>>2nd:
>>====	Issue: we don't need pid virtualization, instead simply use
>><container,pid> pair.
>>
>>This requires a bit more thought. Essentially that's what I was doing, 
>>but I mangled them into the same pid and using masking to add/remove the 
>>container for internal use. As pointed out by Alan(?), we can indeed 
>>reused the same pid internally many times as long as we can distinguish 
>>during the pid-to-task_struct lookup. This is easily done because, the 
>>caller provides the context hence the container for the lookup.
> 
> 
> This is my preferred approach BY FAR.
> 
> Doing a <container,pid> approach is very natural, and avoids almost all 
> issues. At most, you might want to have a new system call (most naturally 
> just the one that is limited to the "init container" - it the one that we 
> boot up with) that can specify both container and pid explicitly, and see 
> all processes and access all processes. But all "normal" system calls 
> would only ever operate within their container.

That's what the current patch set does.
One "global container" that sees and accesses all and the rest is limited
to their respective "container".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 1 Feb 2006 01:01

Re: [RFC: linux-2.6.16-rc1 patch] jsm: fix for high baud rates problem

"V. Ananda Krishnan" <mansarov <at> us.ibm.com> wrote:
>
> igi serial port console doesn't work when baud rates are set higher 
> than 38400.  So the lookup table and code in jsm_neo.c has been modified 
> and tested.

- All the code you've added is one tabstop too far to the right.

- We can simplify the definition of baud_rates[]

- Using local variable `baud' as a temporary cflag is confusing.

- The baud_rates[] scanning can be simplified.

- local `i' doesn't need the initialiser.

How's this look?

--- 25/drivers/serial/jsm/jsm_neo.c~jsm-fix-for-high-baud-rates-problem-tidy	Tue Jan 31
15:57:46 2006
+++ 25-akpm/drivers/serial/jsm/jsm_neo.c	Tue Jan 31 15:57:46 2006
 <at>  <at>  -965,50 +965,47  <at>  <at>  static void neo_param(struct jsm_channel
 			baud = ch->ch_custom_speed;
 			if (ch->ch_flags & CH_BAUD0)
 				ch->ch_flags &= ~(CH_BAUD0);
-		} else {
-			int i= 0;
-			struct baud_rates {
-				unsigned int rate;
-				unsigned int cflag;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexey Dobriyan | 1 Feb 2006 01:22
Picon

Re: Liyitec PS/2 touch panel driver [PATCH]

On Tue, Jan 31, 2006 at 03:59:20PM -0700, Shaun Jackman wrote:
> I've written an input driver for the Liyitec PS/2 touch panel. The
> patch follows. As this is my first input driver, I'd appreciate any
> feedback.

> 2006-01-31  Shaun Jackman  <sjackman <at> gmail.com>
>
> 	* drivers/input/touchscreen/Kconfig (TOUCHSCREEN_LIYITEC): New item.
> 	* drivers/input/touchscreen/Makefile: Add liyitec driver.
> 	* drivers/input/touchscreen/liyitec.c: New file.
> 	* include/linux/serio.h (SERIO_LIYITEC): New constant.

This is not ChangeLog style Linux is using.

> +static void liyitec_disconnect(struct serio *serio)
> +{
> +	struct liyitec *liyitec = serio_get_drvdata(serio);
> +
> +	input_get_device(liyitec->dev);

What do you want to do with return value?

> +	input_unregister_device(liyitec->dev);
> +	serio_close(serio);
> +	serio_set_drvdata(serio, NULL);
> +	input_put_device(liyitec->dev);
> +	kfree(liyitec);
> +}

> +static void __exit liyitec_exit(void)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alan Cox | 1 Feb 2006 01:06
Picon

Re: GPL V3 and Linux - Dead Copyright Holders

On Maw, 2006-01-31 at 09:57 -0800, Linus Torvalds wrote:
> The fact that the COPYING file has a different copyright really doesn't 
> matter. It's still part of the release. 

Law is about precision and exact wording as well as intent. The exact
wording is "the Program" not "the release". And Program is capitalised
to indicate the use of the definition made earlier. That is: "The
"Program", below, refers to any such program or work, and a "work based
on the Program" means either the Program or any derivative work under
copyright law"

The COPYING file is not derivative and is not by any usual
interpretation part of the program. As I said and showed earlier the
COPYING file cannot be part of the program without contradiction.

Ask a law student if you don't believe me, or do it in equations not
words... 

> It's absolutely not different from having a separate "Release notes" file 
> which specifies the copyright conditions. That's how Linux-0.01 did it: 
> the thing was outside the actual main tar-ball, and sent out both as part 
> of the announcemnt and as a separate file in the same directory on the 
> ftp-site.

The release notes are part of the program. The section starting "NOTE!"
is maybe part of the program (thats a real lawyer question). However
whether it is or not is such clear intent that nobody would win an
argument that you had not said nowdays that it is V2

> I can make very specific arguments for why version 2 ONLY is the specific
(Continue reading)

Permalink | Reply | 1 comment |
headers
Matt Reimer | 1 Feb 2006 01:12
Picon

Re: LED: Add IDE disk activity LED trigger

On 1/31/06, Jordan Crouse <jordan.crouse <at> amd.com> wrote:
> On 31/01/06 21:35 +0100, "Jens Axboe" wrote:
> > Perhaps a generic solution isn't feasible, because this isn't really a
> > generic problem. The LED stuff has very limited use - you mention
> > embedded platforms, perhaps they should just be doing this on their own?
>
> Possibly, but what you'll find is that many different embedded platforms
> end up wanting similar behavior, and if they all do it on their own, that
> ends up in a mess.

Indeed. This LED code is exactly what we need for just about every
linux handheld in existence. Please include it.

Matt
Permalink | Reply | 0 comments |
headers
Bill Davidsen | 1 Feb 2006 01:15

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

Joerg Schilling wrote:
> Phillip Susi <psusi <at> cfl.rr.com> wrote:
> 
> 
>>Joerg Schilling wrote:
>>
>>>I am sorry to see your recent dicussion style.
>>>
>>>I was asking a question and I did get a completely useless answer as
>>>any person who has some basic know how Linux SCSI would know that
>>>doing a stat("/dev/sg*", ...) will not return anything useful.
>>>  
>>
>>It certainly does return something useful, just not what you are looking 
>>for.  It does not return information that allows you to cleanly build 
>>your bus:device:lun view of the world, but it does return sufficient 
>>information to enumerate and communicate with all devices in the 
>>system.  Is that not sufficient to be able to implement cdrecord?  If it 
>>is, then the real issue here is that you want Linux to conform to the 
>>bus:device:lun world view, which it seems many people do not wish to do. 
> 
> 
> It does not allow libscg to find all devices.
> 
> 
>>Maybe it would be more constructive if you were to make a good argument 
>>for why the bus:device:lun view is better than /dev/*, but right now it 
>>seems to me that they are just two different ways of doing the same 
>>thing, and you prefer one way while the rest of the Linux developers 
>>prefer the other.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Linus Torvalds | 1 Feb 2006 01:18

Re: GPL V3 and Linux - Dead Copyright Holders


On Tue, 31 Jan 2006, Alan Cox wrote:
> 
> I would argue its irrelevance

Well, I can absolutely agree with that.

It really wasn't ever meant to _change_ anything, so it definitely should 
be irrelevant in that sense. 

That said, I think it actually hass one big result: we may be discussing 
this for a couple of weeks, but I'm pretty sure we won't be discussing it 
for months and having a huge split over it in the kernel community. 

Which to me makes it less-than-irrelevant ;)

I actually tend to have two very different kinds of worries:

 - the technical problem of the month. Something doesn't work, and we 
   don't know why, and it's been broken for long enough that it seems to 
   be pretty fundamental.

   These things worry me, but they don't keep me up at night. 

 - the worry that somebody who submitted code to the kernel feels that his 
   code is mis-used and feels let down by the process.

   This thing _worries_ me. This is something I end up losing sleep over.

The second case is unusual, but it does happen. Things like the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Jakma | 1 Feb 2006 01:20
Picon

Re: GPL V3 and Linux - Dead Copyright Holders

<trimming the wide Cc list due to complaints>

On Tue, 31 Jan 2006, Linus Torvalds wrote:

> Notice how the GPLv2 text says that it applies to any program that 
> just says it is licensed under the General Public License.
>
> I'm convinced _that_ is how you get "no version specified" in section 9.
> You have a program that just says "This is licensed under the GPL",
> instead of doing the full thing.

> And I say that the Linux kernel has contained a notice placed by the
> copyright holder (the "COPYING" file) that says that it's to be
> distributed under (and I quote from the top):
>
>                    GNU GENERAL PUBLIC LICENSE
>                       Version 2, June 1991
>
> and that's it.

Well, most people would recognise this to be exactly the same text of 
the GPLv2 as published by the FSF, as used by many software 
programmes:

 	http://www.gnu.org/licenses/gpl.txt

and hence would have trouble recognising that you intended this to 
also be the text governing exactly which version(s) of the GPL apply 
linux specifically.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Jones | 1 Feb 2006 01:19
Picon
Favicon

Re: 2.6.16-rc1-mm4

On Tue, Jan 31, 2006 at 02:45:58PM -0800, Avuton Olrich wrote:
 > On 1/29/06, Andrew Morton <akpm <at> osdl.org> wrote:
 > >
 > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc1/2.6.16-rc1-mm4/
 > 
 > I'm getting a kernel panic on my Libretto L5 on boot, I don't have a
 > serial port on this laptop, I don't have time at the moment to setup
 > netconsole, and it doesn't get the full information. Hopefully this
 > picture helps a bit:
 > 
 > http://68.111.224.150:8080/P1010306.JPG
 > 
 > If it doesn't help I will attempt to get a netconsole on this computer
 > on the near future.

Thomas recently changed cpufreq_update_policy to call cpufreq_out_of_sync()
to resync when the BIOS changed the frequency behind our back.
The div by 0 trace fingers that code, but I'm puzzled what we're actually
dividing there.
		
		Dave
Permalink | Reply | 3 comments |
headers
John Klingler | 1 Feb 2006 01:24

Re: Compile warnings in XFS, kernel 2.6.15.1

The 2.6.11.1 source doesn't line up with your line numbers so I can't 
say. You'll have to see whether it's stuffing a 64 bit number into a 32 
bit number or vice versa and see if that will cause problems. I don't 
get those error messages when I compile the kernel so maybe someone put 
a cast in or fixed something. There are still plenty of warnings about 
uninitialized variable and so on which I would feel more comfortable not 
seeing. 111 the last time.

John

L. A. Walsh wrote:

> Are these warnings anything to worry about?
>
>  CC      fs/xfs/xfs_bmap.o
>  LD      fs/udf/udf.o
>  LD      fs/udf/built-in.o
>  CC      fs/dnotify.o
>  CC      fs/xfs/xfs_bmap_btree.o
> fs/xfs/xfs_bmap.c: In function `xfs_bmap_search_extents':
> fs/xfs/xfs_bmap.c:3590: warning: long long unsigned int format, 
> different type arg (arg 5)
>  CC      fs/xfs/xfs_btree.o
>  CC      fs/xfs/xfs_buf_item.o
>  CC      fs/xfs/xfs_iget.o
>  CC      fs/xfs/xfs_inode.o
>  CC      fs/xfs/xfs_inode_item.o
>  CC      fs/xfs/xfs_iocore.o
>  CC      fs/xfs/xfs_iomap.o
>  CC      fs/xfs/xfs_itable.o
(Continue reading)

Permalink | Reply | 0 comments |

Gmane