Re: Kernel SCM saga..

[Albert Cahalan]

Linus Torvalds writes:

> NOTE! I detest the centralized SCM model, but if push comes to shove,
> and we just _can't_ get a reasonable parallell merge thing going in
> the short timeframe (ie month or two), I'll use something like SVN
> on a trusted site with just a few committers, and at least try to
> distribute the merging out over a few people rather than making _me_
> be the throttle.
>
> The reason I don't really want to do that is once we start doing
> it that way, I suspect we'll have a _really_ hard time stopping.
> I think it's a broken model. So I'd much rather try to have some
> pain in the short run and get a better model running, but I just
> wanted to let people know that I'm pragmatic enough that I realize
> that we may not have much choice.

I think you at least instinctively know this, but...

Centralized SCM means you have to grant and revoke commit access,
which means that Linux gets the disease of ugly BSD politics.

Under both the old pre-BitKeeper patch system and under BitKeeper,
developer rank is fuzzy. Everyone knows that some developers are
more central than others, but it isn't fully public and well-defined.
You can change things day by day without having to demote anyone.
While Linux development isn't completely without jealousy and pride,
few have stormed off (mostly IDE developers AFAIK) and none have
forked things as severely as OpenBSD and DragonflyBSD.

You may rank developer X higher than developer Y, but they have
only a guess as to how things are. Perhaps developer X would be
a prideful jerk if he knew. Perhaps developer Y would quit in
resentment if he knew.

Whatever you do, please avoid the BSD-style politics.

(the MAINTAINERS file is bad enough; it has caused problems)


-
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: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Glenn Maynard]

(Henning Makholm, I assume; I seem to be missing the actual message and
David's mailer forgot to put a quote header on the original reply):

> > >> I think the "derivative work" angle is a red herring. I do not think
> > >> that either of the two parts that are being linked together (i.e. the
> > >> driver and the firmware) are derivates of the other.  The relevant

The two parts are not derivatives of each other, of course; that's
obvious.  (If I take your firmware, David's firmware loader, and link
them together, I havn't change either of your works.)  The resulting
linked binary, however, is a derivative work of both.

I've heard the claim, several times, that that creating a derivative
work requires creative input, that linking stuff together with "ld" is
completely uncreative, therefore no derivative work is created.  (I'm
not sure if you're making (here or elsewhere) that claim, but it seems
like it.)  What's the basis for this claim?  (If you're not making it,
anybody that does believe this is free to respond.)

The case David referred to[1] says "A derivative work may itself be
copyrighted if it has the requisite originality."  This seems to imply
that something can be a derivative work without creative input (though
no new copyright would exist beyond that of the source objects).  It
seems that while "creative input" is required for copyright to exist,
it is not required for creating a derivative work.

[1] http://caselaw.lp.findlaw.com/data2/circs/8th/033112p.pdf

On Sat, Apr 09, 2005 at 08:07:03PM -0700, David Schwartz wrote:
>   The way you stop someone from distributing part of your work is by 
> arguing
> that the work they are distributing is a derivative work of your work and
> they had no right to *make* it in the first place. See, for example, Mulcahy
> v. Cheetah Learning.

Er, that's one way, but not *the* way.  I could grant you permission to
create derivatives of my work, but not to redistribute them.  To stop you
from distributing them, I'd argue that you had no right to distribute
them--you *did* have the right to make it in the first place.

The GPL does this.  Note GPL #2b: "any work that you distribute or publish".
If you don't distribute or publish the derivative work, the work does not
need to be "licensed ... under the terms of this License."  It very carefully
separates the permissions granted for merely creating a derivative work,
and the permissions granted for distributing those works; if you distribute
a linked binary in violation of the GPL, you may very well have had permission
to make it in the first place.

(Of course, if whether the work is a derivative is in question, that would
need to be established--you would, indeed, need to argue that the work they
are distributing is a derivative work--but you wouldn't necessarily further
argue that they had no right to make it in the first place.)

-- 
Glenn Maynard
-
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 linux-misc-2.6] scsi: remove volatile from scsi data structures

[Tejun Heo]

 Hello, James.
 Hello, Christoph.

 This patch removes volatile qualifier from scsi_device->device_busy,
Scsi_Host->host_busy and ->host_failed as the volatile qualifiers
don't serve any purpose now.  While at it, convert those fields from
unsigned short to unsigned int as suggested by Christoph.


Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>


Index: scsi-reqfn-export/include/scsi/scsi_device.h
===
--- scsi-reqfn-export.orig/include/scsi/scsi_device.h   2005-04-10 
13:03:14.0 +0900
+++ scsi-reqfn-export/include/scsi/scsi_device.h2005-04-10 
13:04:42.0 +0900
@@ -43,7 +43,8 @@ struct scsi_device {
struct list_headsiblings;   /* list of all devices on this host */
struct list_headsame_target_siblings; /* just the devices sharing 
same target id */
 
-   volatile unsigned short device_busy;/* commands actually active on 
low-level */
+   unsigned int device_busy;   /* commands actually active on
+* low-level. protected by queue_lock. 
*/
spinlock_t sdev_lock;   /* also the request queue_lock */
spinlock_t list_lock;
struct list_head cmd_list;  /* queue of in use SCSI Command 
structures */
Index: scsi-reqfn-export/include/scsi/scsi_host.h
===
--- scsi-reqfn-export.orig/include/scsi/scsi_host.h 2005-04-10 
13:03:14.0 +0900
+++ scsi-reqfn-export/include/scsi/scsi_host.h  2005-04-10 13:04:42.0 
+0900
@@ -448,8 +448,14 @@ struct Scsi_Host {
wait_queue_head_t   host_wait;
struct scsi_host_template *hostt;
struct scsi_transport_template *transportt;
-   volatile unsigned short host_busy;   /* commands actually active on 
low-level */
-   volatile unsigned short host_failed; /* commands that failed. */
+
+   /*
+* The following two fields are protected with host_lock;
+* however, eh routines can safely access during eh processing
+* without acquiring the lock.
+*/
+   unsigned int host_busy;/* commands actually active on 
low-level */
+   unsigned int host_failed;  /* commands that failed. */
 
unsigned short host_no;  /* Used for IOCTL_GET_IDLUN, /proc/scsi et al. 
*/
int resetting; /* if set, it means that last_reset is a valid value */
-
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: Kernel SCM saga..

[Paul Jackson]

Linus wrote:
> Almost everything
> else keeps the  in the ASCII hexadecimal representation, and I
> should have done that here too. Why? Not because it's a  - hey, the 
> binary representation is certainly denser and equivalent

Since the size of  ASCII sha1's is only about 18% larger
than the size of the same number of binary sha1's , I
don't see you gain much from the binary.

I cast my non-existent vote for making the sha1 ascii - while you still can ;).

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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: Processes stuck on D state on Dual Opteron

[Claudio Martins]

On Sunday 10 April 2005 03:53, Nick Piggin wrote:
>
> Looks like you may possibly have a memory allocation deadlock
> (although I can't explain the NMI oops).
>
> I would be interested to see if the following patch is of any
> help to you.
>

  Hi Nick,

  I'll build a kernel with your patch and report on the results as soon as 
possible.

 Thanks 

Claudio

-
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: Processes stuck on D state on Dual Opteron

[Claudio Martins]

On Sunday 10 April 2005 03:47, Andrew Morton wrote:
>
> Suggest you boot with `nmi_watchdog=0' to prevent the nmi watchdog from
> cutting in during long sysrq traces.
>
> Also, capture the `sysrq-m' output so we can see if the thing is out of
> memory.

  OK, will do it ASAP and report back.

 Thanks,

Claudio

-
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: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[David Schwartz]

> Scripsit "David Schwartz" <[EMAIL PROTECTED]>

> >> I think the "derivative work" angle is a red herring. I do not think
> >> that either of the two parts that are being linked together (i.e. the
> >> driver and the firmware) are derivates of the other.  The relevant
> >> point is that distribution of the linked _result_ is nevertheless
> >> subject to the condition in GPL #2, which is in general the only
> >> source we have for a permission to distribute a non-verbatim-source
> >> form of the driver.

> > If the thing distributed is not the covered work and not a
> > derivative work, why does the GPL apply to it at all?

> You are free to not apply the GPL to it.

> However, then you cannot legally copy it at all, because it contains
> part of the original author's copyrighted work and therefore can only
> legally be copied with the permission of the author.

The way you stop someone from distributing part of your work is by 
arguing
that the work they are distributing is a derivative work of your work and
they had no right to *make* it in the first place. See, for example, Mulcahy
v. Cheetah Learning.

My point is that the reason the derivative work issue is so important is
because it's the only way (in U.S. law anyway) that the GPL can apply to
anything other than the exact thing the author chose to apply it to. The GPL
applies to distributing a Linux binary I just made even though nobody ever
chose to apply the GPL to the binary I just made only because the binary I
just made is a derivative work of the Linux kernel, and the authors of that
work chose to apply the GPL to it.

DS


-
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: Processes stuck on D state on Dual Opteron

[Nick Piggin]

Claudio Martins wrote:
On Tuesday 05 April 2005 03:12, Andrew Morton wrote:
Claudio Martins <[EMAIL PROTECTED]> wrote:
  While stress testing 2.6.12-rc2 on an HP DL145 I get processes stuck
in D state after some time.
  This machine is a dual Opteron 248 with 2GB (ECC) on one node (the
other node has no RAM modules plugged in, since this board works only
with pairs).
  I was using stress (http://weather.ou.edu/~apw/projects/stress/) with
the following command line:
stress -v -c 20 -i 12 -m 10 -d 20
[snip]

  Unfortunately the system Oopsed in the middle of dumping the tasks, but from 
what I can see I'm tempted to think that this might be related to the MD 
code. md2_raid1 is blocked on D state and, although not shown on the dump, I 
know from ps command that md0_raid1 (the swap partition) was also on D state 
(along with the stress processes which are responsible for hogging memory, 
and top and df). There were about 200MB swapped out, but the swap partition 
size is 1GB.

Looks like you may possibly have a memory allocation deadlock
(although I can't explain the NMI oops).
I would be interested to see if the following patch is of any
help to you.
Thanks,
Nick
--
SUSE Labs, Novell Inc.



Index: linux-2.6/mm/mempool.c
===
--- linux-2.6.orig/mm/mempool.c 2005-03-30 10:39:51.0 +1000
+++ linux-2.6/mm/mempool.c  2005-03-30 10:41:29.0 +1000
@@ -198,7 +198,10 @@ void * mempool_alloc(mempool_t *pool, in
void *element;
unsigned long flags;
DEFINE_WAIT(wait);
-   int gfp_nowait = gfp_mask & ~(__GFP_WAIT | __GFP_IO);
+   int gfp_nowait;
+   
+   gfp_mask |= __GFP_NORETRY; /* don't loop in __alloc_pages */
+   gfp_nowait = gfp_mask & ~(__GFP_WAIT | __GFP_IO);
 
might_sleep_if(gfp_mask & __GFP_WAIT);
 repeat_alloc:

Re: Processes stuck on D state on Dual Opteron

[Andrew Morton]

Claudio Martins <[EMAIL PROTECTED]> wrote:
>
>   I repeated the test to try to get more output from alt-sysreq-T, but it 
>  oopsed again with even less output. 
>By the way, I have also tested 2.6.11.6 and I get stuck processes in the 
>  same way. With 2.6.9 I get a hard lockup with no working alt-sysrq, after 
>  about 30 to 60mins of stress.

It could be an md deadlock, or it could be an out-of-memory deadlock.  md
trying to allocate memory on the swapout path.

>This is with preempt enabled (as well as BKL preempt). I want to test also 
>  without preempt and also without using MD Raid1, but I'll have to reach the 
>  machine and hit the power button, so not possible until tomorrow :-(
> 
>   The original original message in this thread containing the details of the 
>  setup and a .config is at:
> 
>  http://marc.theaimsgroup.com/?l=linux-kernel=111266784320156=2
> 
>I am happy to test any patches and also wonder if enabling any of the 
>  options in the kernel debugging section could help in trying to find where 
>  the deadlock is.

Suggest you boot with `nmi_watchdog=0' to prevent the nmi watchdog from
cutting in during long sysrq traces.

Also, capture the `sysrq-m' output so we can see if the thing is out of
memory.
-
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: Re: more git updates..

[Petr Baudis]

Dear diary, on Sun, Apr 10, 2005 at 01:31:10AM CEST, I got a letter
where Linus Torvalds <[EMAIL PROTECTED]> told me that...
> On Sat, 9 Apr 2005, Linus Torvalds wrote:
> > 
> > Actually, I guess I wouldn't have to change the format. I could just 
> > extend the existing "tree" object to be able to point to other trees, and 
> > that's it.
> 
> Done, and pushed out. The current git.git repository seems to do all of 
> this correctly.
..snip..

Ok, so now I can dare announce it, I hope. I hacked my branch of git
somewhat, kept in sync with Linus, and now I have something to show.
Please see it at

http://pasky.or.cz/~pasky/dev/git/

It is basically a set of (still rather crude) shell scripts upon Linus'
git, which make it sanely usable by mere humans for actual version
tracking. Its usage _is_ going to change, so don't get too used to it
(that'd be hard anyway, I suspect), but it should be working nicely.

I have described most of the interesting parts and some basic usage in
the README at that page. It wraps commits, supports log retrieval and
comfortable diffing between any two trees. And on top of that, it can do
some basic remote repositories - it will pull (rsync) from them and it
can make the local copy track them - on pull, it will be updated
accordingly (and your local commits on the tracked branch will get
orphaned).

I didn't attach a patch against Linus since I think it's pretty much
useless now. It's available as against-linus.patch on the web, and
you can apply it to the latest git tree (NOT 0.03). But it's probably
better idea to wget my tree. You can then watch us making progress by

gitpull.sh linus
gitpull.sh pasky

and see where we differ by:

gitdiff.sh linus pasky

(This is how the against-linus.patch was generated. I'd easily generate
even 0.03 patch this way, but I forgot to merge the fsck at that time,
so it would suck.)

(Note that the tree you wget is set up to track my branch. If you want
to stop tracking it (basically necessary now if you want to do local
commits), do:

cp .dircache/HEAD .dircache/HEAD.local
gittrack.sh

The cp says that something like "I want to pick up where the tracked
branch left off". Otherwise, untracking would return you to your "local"
branch, which is just some ancient predecessor of the pasky branch here
anyway.)

Note that I didn't really test it on anything but git itself yet, so I'm
not sure how will it cope especially with directories - I tried to make
it aware of them though. I will do some more practical testing tomorrow.

Otherwise, I will probably try to consolidate the usage and
documentation now, and beautify the scripts. I might start pondering
some merging too. Oh, and gitpatch.sh. :-)

Have fun and please share your opinions,

-- 
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
98% of the time I am right. Why worry about the other 3%.
-
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/

increasing scsi_max_sg / max_segments for scsi writes/reads

[sai narasimhamurthy]

Hi, 
I had posted a question on increasing the scsi
read/write sectors  per command. I figured out some of
the things, but many questions still exist. 

I was wondering why the maximum writes I could get
from a single scsi write command could never exceed
204 
4096B  segments . I traced it to :  

static const int scsi_max_sg = PAGE_SIZE /
sizeof(struct scatterlist)

in scsi_merge.c .(which amounts to 204)  

Is this the limit of the maximum blocks we can
read/write through a single scsi command, atleast for
the given kernel (2.4.29) ? How can I increase
it??

I am on a P3 Dell poweredgde 2400 . 

Sai 

  










__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-
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: Processes stuck on D state on Dual Opteron

[Claudio Martins]

On Tuesday 05 April 2005 03:12, Andrew Morton wrote:
> Claudio Martins <[EMAIL PROTECTED]> wrote:
> >While stress testing 2.6.12-rc2 on an HP DL145 I get processes stuck
> > in D state after some time.
> >This machine is a dual Opteron 248 with 2GB (ECC) on one node (the
> > other node has no RAM modules plugged in, since this board works only
> > with pairs).
> >
> >I was using stress (http://weather.ou.edu/~apw/projects/stress/) with
> > the following command line:
> >
> >  stress -v -c 20 -i 12 -m 10 -d 20
> >
> >This causes a constant load avg. of around 70, makes the machine go
> > into swap a little, and writes up to about 20GB of random data to disk
> > while eating up all CPU. After about half and hour random processes like
> > top, df, etc get stuck in D state. Half of the 60 or so stress processes
> > are also in D state. The machine keeps being responsive for maybe some 15
> > minutes but then the shells just hang and sshd stops responding to
> > connections, though the machine replies to pings (I don't have console
> > acess till tomorrow).
> >
> >The system is using ext3 with md software Raid1.
> >
> >   I'm interested in knowing if anyone out there with dual Opterons can
> >  reproduce this or not. I also have access to an HP DL360 Dual Xeon, so I
> > will try to find out if this is AMD64 specific as soon as possible.
> > Please let me know if you want me to run some other tests or give some
> > more info to help solve this one.
>
> Can you capture the output from alt-sysrq-T?


 Hi Andrew,

  Due to other tasks, only now was I able to repeat the tests and capture the 
the output from alt-sysrq-T. I booted with serial console, put stress to work 
and when the processes started to get hung on D state I managed to capture 
the following:

 SysRq : Show State

   sibling
  task PC  pid father child younger older
init  D 81007fcfe0d8 0 1  0 2   
(NOTLB)
810003253768 0082 81007fd19170 007d 
   81007fd19170 810003251470 271b 810074468e70 
   810003251680 8027a79a 
Call Trace:{__make_request+1274} 
{__down+152} 
   {default_wake_function+0} 
{mempool_alloc+164} 
   {__down_failed+53} 
{.text.lock.md+155} 
   {make_request+868} 
{cache_alloc_refill+413} 
   {generic_make_request+545} 
{autoremove_wake_function+0} 
   {autoremove_wake_function+0} 
{submit_bio+223} 
   {test_set_page_writeback+203} 
{swap_writepage+184} 
   {shrink_zone+2678} 
{thread_return+0} 
   {thread_return+88} 
{try_to_free_pages+311} 
   {autoremove_wake_function+0} 
{__alloc_pages+533} 
   {__get_free_pages+14} 
{__pollwait+74} 
   {pipe_poll+66} {do_select+725} 
   {__pollwait+0} {sys_select+735} 
   {system_call+126} 
migration/0   S 810002c12720 0 2  1 3   
(L-TLB)
81007ff0fea8 0046 810074806ef0 00750001 
   81007ff0fe58 8100032506f0 0129 810075281230 
   810003250900 810072ffde88 
Call Trace:{migration_thread+532} 
{migration_thread+0} 
   {kthread+217} {child_rip+8} 
   {kthread+0} {child_rip+0} 
   
ksoftirqd/0   S  0 3  1 4 2 
(L-TLB)
81007ff11f08 0046 810072e00430 007d 
   810002c194e0 810003250030 00d1 810072f3a030 
   810003250240  
Call Trace:{__do_softirq+113} 
{ksoftirqd+0} 
   {ksoftirqd+0} {ksoftirqd+99} 
   {ksoftirqd+0} {kthread+217} 
   {child_rip+8} {kthread+0} 
   {child_rip+0} 
migration/1   S 810002c1a720 0 4  1 5 3 
(L-TLB)
81007ff15ea8 0046 810072d1cff0 00730001 
   810079fe7e98 81007ff134b0 00a3 810075281230 
   81007ff136c0 81003381de88 
Call Trace:{migration_thread+532} 
{migration_thread+0} 
   {kthread+217} {child_rip+8} 
   {kthread+0} {child_rip+0} 
   
ksoftirqd/1   S 0001 0 5  1 6 4 
(L-TLB)
81007ff19f08 0046 810075376db0 0077802b8e7e 
   810002c114e0 81007ff12df0 01b4 810074125130 
   81007ff13000  
Call Trace:{__do_softirq+113} 
{ksoftirqd+0} 
   {ksoftirqd+0} {ksoftirqd+99} 
   {ksoftirqd+0} {kthread+217} 
   {child_rip+8} {kthread+0} 
   {child_rip+0} 
events/0  S 094f2f7a804e 0 6  1 7 5 
(L-TLB)
81007ff3be58 0046 0246 8013d00d 
   7ffe0c00 81007ff12730 0c80 803f40c0 
   81007ff12940  
Call Trace:{__mod_timer+317} 
{cache_reap+0} 
   {worker_thread+305} 
{default_wake_function+0} 
   

Re: more git updates..

[Paul Jackson]

>From before:

The sha1 (ascii) digests for 16817 files take:

689497 bytes before compression
397475 bytes after minigzip

New numbers:

The sha1 (binary) digests for 16817 files take:

336340 bytes before compression
334943 bytes after minigzip

So compressing binary digests isn't worth a darn, and compressing ascii
digests gets them down to within 18% of binary digests in size.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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: more git updates..

[Paul Jackson]

> Then a "tree" object would point to a "directory" object, 

Ah - light bulb flickers - in _separate_ files.

Yes, that obviously makes a difference.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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: more git updates..

[Paul Jackson]

Linus wrote:
> Damn, that's painful. I suspect I will have to change the format somehow.

The sha1 (ascii) digests for 16817 files take:

689497 bytes before compression
397475 bytes after minigzip

The pathnames, relative to top of tree, for these 16817
files take:

503983 bytes before compression
 85786 bytes after minigzip compression

I doubt any fancifying up of the pathname storage will gain much.

However going from binary to ascii sha1 digest might help (compresses
better, I suspect - I'll have to write a few lines of code to see).

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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: Kernel SCM saga..

[Paul Jackson]

Chris wrote:
> How many is alot?  Are we talking 100k, 1m, 10m?

I pulled some numbers out of my bk tree for Linux.

I have 16817 source files.

They average 12.2 bitkeeper changes per file (counting the number of
changes visible from doing 'bk sccslog' on each of the 16817 files). 

These 16817 files consume:

224 MBytes uncompressed and
 95 MBytes compressed

(using zlib's minigzip, on a 4 KB page reiserfs.)

Since each change will get its own copy of the file, multiplying these
two sizes (224 and 95) by 12.2 changes per file means the disk cost
would be:

2.73 GByte uncompressed, or
1.16 GBytes compressed.

I was pleasantly surprised at the degree of compression, shrinking files
to 42% of their original size.  I expected, since the classic rule of
thumb here to archive before compressing wasn't being followed (nor
should it be) and we were compressing lots a little files, we would save
fewer disk blocks than this.

Of course, since as Linus reminds us, it's disk buffers in memory,
not blocks on disk, that are precious, it's more like we will save
224 - 95 == 129 MBytes of RAM to hold one entire tree.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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: Re: Re: Kernel SCM saga..

[Phillip Lougher]

On Apr 10, 2005 2:42 AM, Petr Baudis <[EMAIL PROTECTED]> wrote:
> Dear diary, on Sun, Apr 10, 2005 at 03:01:12AM CEST, I got a letter
> where Phillip Lougher <[EMAIL PROTECTED]> told me that...
> > On Apr 9, 2005 3:53 AM, Petr Baudis <[EMAIL PROTECTED]> wrote:
> >
> > >   FWIW, I made few small fixes (to prevent some trivial usage errors to
> > > cause cache corruption) and added scripts gitcommit.sh, gitadd.sh and
> > > gitlog.sh - heavily inspired by what already went through the mailing
> > > list. Everything is available at http://pasky.or.cz/~pasky/dev/git/
> > > (including .dircache, even though it isn't shown in the index), the
> > > cumulative patch can be found below. The scripts aim to provide some
> > > (obviously very interim) more high-level interface for git.
> >
> > I did a bit of playing about with the changelog generate script,
> > trying to produce a faster version.  The attached version uses a
> > couple of improvements to be a lot faster (e.g. no recursion in the
> > common case of one parent).
> >
> > FWIW it is 7x faster than makechlog.sh (4.342 secs vs 34.129 secs) and
> > 28x faster than gitlog.sh (4.342 secs vs 2 mins 4 secs) on my
> > hardware.  You mileage may of course vary.
> 
> Wow, really impressive! Great work, I've merged it (if you don't object,
> of course).

Of course I don't object...

> 
> Wondering why I wasn't in the Cc list, BTW.

Weird, it wasn't intentional.  I read LKML in Gmail (which I don't use
for much else), and just clicked "reply", expecting to do the right
thing.  Replying to this email it's also left you off the CC list. 
Looking at the email source I believe it's probably to do with the
following:

Mail-Followup-To: Linus Torvalds <[EMAIL PROTECTED]>,
[EMAIL PROTECTED],
Kernel Mailing List > 

I've CC'd you explicitly on this.

Phillip
-
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: Re: Re: Kernel SCM saga..

[Petr Baudis]

Dear diary, on Sun, Apr 10, 2005 at 03:01:12AM CEST, I got a letter
where Phillip Lougher <[EMAIL PROTECTED]> told me that...
> On Apr 9, 2005 3:53 AM, Petr Baudis <[EMAIL PROTECTED]> wrote:
> 
> >   FWIW, I made few small fixes (to prevent some trivial usage errors to
> > cause cache corruption) and added scripts gitcommit.sh, gitadd.sh and
> > gitlog.sh - heavily inspired by what already went through the mailing
> > list. Everything is available at http://pasky.or.cz/~pasky/dev/git/
> > (including .dircache, even though it isn't shown in the index), the
> > cumulative patch can be found below. The scripts aim to provide some
> > (obviously very interim) more high-level interface for git.
> 
> I did a bit of playing about with the changelog generate script,
> trying to produce a faster version.  The attached version uses a
> couple of improvements to be a lot faster (e.g. no recursion in the
> common case of one parent).
> 
> FWIW it is 7x faster than makechlog.sh (4.342 secs vs 34.129 secs) and
> 28x faster than gitlog.sh (4.342 secs vs 2 mins 4 secs) on my
> hardware.  You mileage may of course vary.

Wow, really impressive! Great work, I've merged it (if you don't object,
of course).

Wondering why I wasn't in the Cc list, BTW.

-- 
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
98% of the time I am right. Why worry about the other 3%.
-
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: more git updates..

[Paul Jackson]

Bernd wrote:
> more parser friendly to have single records for diffs.

good point

[looks like you trimmed the cc list - folks around here don't like that ;)]

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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: more git updates..

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Ralph wrote:
>> Watch out for when xargs invokes do_something more than once and the `<'
>> is parsed by a different one than the `>'.
> It will take a pretty long list to do that.  It seems that
> GNU xargs on top of a Linux kernel has a 128 KByte ARG_MAX.
> In the old days, with 4 KByte ARG_MAX limits, this would have
> bitten us pretty quickly.

Nevertheless I  think it is more parser friendly to have single records for
diffs.

Greetings
Bernd
-
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: Re: Kernel SCM saga..

[Phillip Lougher]

On Apr 9, 2005 3:53 AM, Petr Baudis <[EMAIL PROTECTED]> wrote:

>   FWIW, I made few small fixes (to prevent some trivial usage errors to
> cause cache corruption) and added scripts gitcommit.sh, gitadd.sh and
> gitlog.sh - heavily inspired by what already went through the mailing
> list. Everything is available at http://pasky.or.cz/~pasky/dev/git/
> (including .dircache, even though it isn't shown in the index), the
> cumulative patch can be found below. The scripts aim to provide some
> (obviously very interim) more high-level interface for git.

I did a bit of playing about with the changelog generate script,
trying to produce a faster version.  The attached version uses a
couple of improvements to be a lot faster (e.g. no recursion in the
common case of one parent).

FWIW it is 7x faster than makechlog.sh (4.342 secs vs 34.129 secs) and
28x faster than gitlog.sh (4.342 secs vs 2 mins 4 secs) on my
hardware.  You mileage may of course vary.

Regards

Phillip

--
#!/bin/sh

changelog() {
local parents new_parent
declare -a new_parent

new_parent[0]=$1
parents=1

while [ $parents -gt 0 ]; do
parent=${new_parent[$((parents-1))]}
echo $parent >> $TMP
cat-file commit $parent > $TMP_FILE

echo me $parent
cat $TMP_FILE
echo -e "\n--\n"

parents=0
while read type text; do
if [ $type = 'committer' ]; then
break;
elif [ $type = 'parent' ] &&
! grep -q $text $TMP ; then
new_parent[$parents]=$text
parents=$((parents+1))
fi
done < $TMP_FILE

i=0
while [ $i -lt $((parents-1)) ]; do
changelog ${new_parent[$i]}
i=$((i+1))
done
done
}

TMP=`mktemp`
TMP_FILE=`mktemp`

base=$1
if [ ! "$base" ]; then
base=$(cat .dircache/HEAD)
fi
changelog $base
rm -rf $TMP $TMP_FILE
-
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: more git updates..

[Paul Jackson]

Ralph wrote:
> Watch out for when xargs invokes do_something more than once and the `<'
> is parsed by a different one than the `>'.

It will take a pretty long list to do that.  It seems that
GNU xargs on top of a Linux kernel has a 128 KByte ARG_MAX.

In the old days, with 4 KByte ARG_MAX limits, this would have
bitten us pretty quickly.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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: Kernel SCM saga..

[Paul Jackson]

David wrote:
> recovery is more difficult when you corrupt some
> file in your repository.

Agreed.  I too have recovered RCS and SCCS files by hand editing.


Linus wrote:
> I don't want people editing repostitory files by hand.

Tyrant !;)

>From Wikipedia:

A tyrant is a usurper of rightful power.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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: Kernel SCM saga..

[Chris Wedgwood]

On Sat, Apr 09, 2005 at 04:13:51PM -0700, Linus Torvalds wrote:

> > I understand the arguments for compression, but I hate it for one
> > simple reason: recovery is more difficult when you corrupt some
> > file in your repository.

I've had this too.  Magic binary blobs are horrible here for data loss
which is why I'm not keen on subversion.

> Trust me, the way git does things, you'll have so much redundancy
> that you'll have to really _work_ at losing data.

It's not clear to me that compression should be *required* though.
Shouldn't we be able to turn this off in some cases?

> The bad news is that this is obviously why it does eat a lot of
> disk.

Disk is cheap, but sadly page-cache is not :-(

> Since it saves full-file commits, you're going to have a lot of
> (compressed) full files around.

How many is alot?  Are we talking 100k, 1m, 10m?
-
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: [2.6 patch] drivers/serial/jsm/: make 2 functions static

[Kilau, Scott]

Thanks Adrian for helping clean up the driver.
 
Wendy will integrate your patch into our source tree.
 
Scott



From: Adrian Bunk [mailto:[EMAIL PROTECTED]
Sent: Sat 4/9/2005 1:04 PM
To: Andrew Morton
Cc: Kilau, Scott; linux-kernel@vger.kernel.org
Subject: [2.6 patch] drivers/serial/jsm/: make 2 functions static



- Forwarded message from Adrian Bunk <[EMAIL PROTECTED]> -

Date:   Sat, 2 Apr 2005 01:38:51 +0200
From: Adrian Bunk <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org
Subject: [2.6 patch drivers/serial/jsm/: make 2 functions static

This patch makes two needlessly global functions static.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was already sent on:
- 2 Apr 2005

 drivers/serial/jsm/jsm.h |1 -
 drivers/serial/jsm/jsm_neo.c |2 +-
 drivers/serial/jsm/jsm_tty.c |4 +++-
 3 files changed, 4 insertions(+), 3 deletions(-)

--- linux-2.6.12-rc1-mm4-full/drivers/serial/jsm/jsm_neo.c.old  2005-04-02 
00:20:17.0 +0200
+++ linux-2.6.12-rc1-mm4-full/drivers/serial/jsm/jsm_neo.c  2005-04-02 
00:20:34.0 +0200
@@ -688,7 +688,7 @@
 /*
  * No locks are assumed to be held when calling this function.
  */
-void neo_clear_break(struct jsm_channel *ch, int force)
+static void neo_clear_break(struct jsm_channel *ch, int force)
 {
u64 lock_flags;

--- linux-2.6.12-rc1-mm4-full/drivers/serial/jsm/jsm.h.old  2005-04-02 
00:20:44.0 +0200
+++ linux-2.6.12-rc1-mm4-full/drivers/serial/jsm/jsm.h  2005-04-02 
00:20:54.0 +0200
@@ -393,7 +393,6 @@
 int jsm_uart_port_init(struct jsm_board *);
 int jsm_remove_uart_port(struct jsm_board *);
 void jsm_input(struct jsm_channel *ch);
-void jsm_carrier(struct jsm_channel *ch);
 void jsm_check_queue_flow_control(struct jsm_channel *ch);

 #endif
--- linux-2.6.12-rc1-mm4-full/drivers/serial/jsm/jsm_tty.c.old  2005-04-02 
00:21:02.0 +0200
+++ linux-2.6.12-rc1-mm4-full/drivers/serial/jsm/jsm_tty.c  2005-04-02 
00:21:18.0 +0200
@@ -31,6 +31,8 @@

 #include "jsm.h"

+static void jsm_carrier(struct jsm_channel *ch);
+
 static inline int jsm_get_mstat(struct jsm_channel *ch)
 {
unsigned char mstat;
@@ -760,7 +762,7 @@
jsm_printk(IOCTL, INFO, >ch_bd->pci_dev, "finish\n");
 }

-void jsm_carrier(struct jsm_channel *ch)
+static void jsm_carrier(struct jsm_channel *ch)
 {
struct jsm_board *bd;




-
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] radeonfb: (#2) Implement proper workarounds for PLL accesses

[Benjamin Herrenschmidt]

On Sat, 2005-04-09 at 18:24 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> 
> > Can you redo the counting of the workarounds with the patch ?
> 
> Switching from X to console:
> 
> radeon_write_pll_regs: INPLL
> radeon_write_pll_regs: INPLL
> radeon_write_mode: OUTPLL
> radeonfb_engine_reset: INPLL
> radeonfb_engine_reset: OUTPLL
> radeonfb_engine_reset: OUTPLL
> radeonfb_setcmap: INPLL
> radeonfb_setcmap: OUTPLL
> radeonfb_setcmap: OUTPLL
> radeon_write_pll_regs: INPLL
> radeon_write_pll_regs: INPLL
> radeon_write_mode: OUTPLL
> radeonfb_engine_reset: INPLL
> radeonfb_engine_reset: OUTPLL
> radeonfb_engine_reset: OUTPLL
> radeonfb_setcmap: INPLL
> radeonfb_setcmap: OUTPLL
> radeonfb_setcmap: OUTPLL
> radeonfb_setcmap: INPLL
> radeonfb_setcmap: OUTPLL
> radeonfb_setcmap: OUTPLL
> radeonfb_setcmap: INPLL
> radeonfb_setcmap: OUTPLL
> radeonfb_setcmap: OUTPLL
> radeonfb_setcmap: INPLL
> radeonfb_setcmap: OUTPLL

Ok, so the above is interesting, something is callign setcmap way too
much here I would say... Besides, it looks like set_par is called twice,
which is wrong too.

> Switching from console to X:
> 
> radeonfb_setcmap: OUTPLL
> radeon_write_pll_regs: INPLL
> radeon_write_pll_regs: INPLL
> radeon_write_mode: OUTPLL
> radeonfb_engine_reset: INPLL
> radeonfb_engine_reset: OUTPLL
> radeonfb_engine_reset: OUTPLL
> radeonfb_setcmap: INPLL
> radeonfb_setcmap: OUTPLL
> radeonfb_setcmap: OUTPLL
> agpgart: Putting AGP V2 device at :00:0b.0 into 1x mode
> agpgart: Putting AGP V2 device at :00:10.0 into 1x mode
> radeonfb_setcolreg: INPLL
> radeonfb_setcolreg: OUTPLL
> radeonfb_setcolreg: OUTPLL
> ... last three lines repeated 63 times

Hrm... the last (serie of 64 setcolreg) are probably X beeing extremely
dumb, and calling the ioctl 64 times to set each palette entry instead
of doing a single call for the whole palette...

Anyway. Except for maybe the double set-par on switch from X to console,
there isn't much more we can do here. We might be able to improve X but
there is a significant lag between a fix done to X.org HEAD appears in
any distro. The fact is, according to ATI, there is a HW bug on M6 taht
can cause lockups of the chip, and this 5ms workaround is necessary to
avoid it... 

Ben.


-
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: Kernel SCM saga..

[Tupshin Harper]

Roman Zippel wrote:
It seems you exported the complete parent information and this is exactly 
the "nitty-gritty" I was "whining" about and which is not available via 
bkcvs or bkweb and it's the most crucial information to make the bk data 
useful outside of bk. Larry was previously very clear about this that he 
considers this proprietary bk meta data and anyone attempting to export 
this information is in violation with the free bk licence, so you indeed 
just took the important parts and this is/was explicitly verboten for 
normal bk users.
 

Yes, this is exactly the information that would be necessary to create a 
general interop tool between bk and darcs|arch|monotone, and is the 
fundamental objection I and others have had to open source projects 
using BK. Is Bitmover willing to grant a special dispensation to allow a 
lossless conversion of the linux history to another format?

-Tupshin
-
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] Add Mac mini sound support

[Benjamin Herrenschmidt]

On Sat, 2005-04-09 at 13:51 +0200, Per Christian Henden wrote:
> The patch below adds sound support on the Mac Mini by making a small change 
> to the PowerMac sound card detection code.
> 
> Details: 
> 
> Original code:
> >From sound/ppc/pmac.c  __init snd_pmac_detect(pmac_t *chip) :
> 
>  chip->model = PMAC_AWACS;
>  ...
>  if (device_is_compatible(sound, "AOAKeylargo")) {
>   ...
>   chip->model = PMAC_SNAPPER;
>   ...
>  }
> 
> The chip model is first set to AWACS, then because the check above returns 
> true, it gets set to SNAPPER.
> Using AWACS gives perfect sound, using SNAPPER gives no sound at all, so it 
> should use AWACS instead.
> Note that the mixer still doesn't work.
> 
> My simple patch makes the mentioned check return false on a Mac Mini.

And is not correct. It might appear to work but it is not the right
thing to do. There is no AWACS chip in there. There is a fixed function
codec controlled by a couple of GPIOs afaik. I'm working on a major
rework of the alsa driver that will include support for the mini and the
G5s.

Ben.


-
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: more git updates..

[Linus Torvalds]

On Sat, 9 Apr 2005, Linus Torvalds wrote:
> 
> Actually, I guess I wouldn't have to change the format. I could just 
> extend the existing "tree" object to be able to point to other trees, and 
> that's it.

Done, and pushed out. The current git.git repository seems to do all of 
this correctly.

NOTE! This means that each "tree" file basically tracks just a single
directory. The old style of "every file in one tree file" still works, but 
fsck-cache will warn about it. Happily, the git archive itself doesn't 
have any subdirectories, so git itself is not impacted by it.

Now, this means that I should add a "recusive" option to "tree-diff", but 
I haven't done so yet. So right now if I change the top-level Makefile,
_and_ change kernel/exit.c, then the "tree diff" between the two commit 
trees ends up looking like:

[EMAIL PROTECTED]:~/lx-test/linux-2.6.12-rc2> diff-tree 
7bec1223736d7e02c755e9a365984b3cbfa1e6e9 
d64817f809a60cd960d3078ae91b4d19cb649501 | tr '\0' '\n'
<100644 e1e7f7430c0297f22042cff58da5ca73ef121b95 Makefile
>100644 8ee21134577e98fb642dffc5b797a0121645c543 Makefile
<4 2239383d00ae746f5e79ceccf8ac3fbca62f949d kernel
>4 a8fad219cb78a6b6a05a10f8643d615fefc8160f kernel

ie it shows that the Makefile blob has changed, and the kernel directory 
has changed. You then need to recurse into the kernel tree to see what the 
changes were there:

[EMAIL PROTECTED]:~/lx-test/linux-2.6.12-rc2> diff-tree 
2239383d00ae746f5e79ceccf8ac3fbca62f949d 
a8fad219cb78a6b6a05a10f8643d615fefc8160f | tr '\0' '\n'
<100644 1a50b58453679b6fee8de4f744f4befc39397bb1 exit.c
>100644 e8df1325bf25816827a1a64404ad533a97bfdae2 exit.c

but it clearly all seems to work. And it means that a subdirectory that 
didn't change at all (the common case) will be able to re-use the old sha1 
file when you create a tree (this may in fact make "diff-tree" much less 
important, since now it tends to handle objects that are just a few kB in 
size, rather than almost a megabyte.

So in this case, the "commit cost" of changing two files was two small 
tree files (1468 and 679 bytes respectively for the kernel/ and top-level 
directory) and the commit file itself (251 bytes). In addition to the 
actual data files that were changed, of course.

Goodie. Big difference between that and the 460kB of the old monolithic
tree file.

Linus
-
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: Status of new kernel.org servers

[Andre Tomt]

H. Peter Anvin wrote:
For those of you that are interested...

I kind of sort of miss the load and bandwidth statistics on the 
kernel.org front page. Did they just go boring now with sufficient 
hardware resources? :-)
-
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: more git updates..

[Ralph Corderoy]

Hi Linus,

> Btw, the NUL-termination makes this really easy to use even in shell
> scripts, ie you can do
> 
>   diff-tree   | xargs -0 do_something
> 
> and you'll get each line as one nice argument to your "do_something"
> script. So a do_diff could be based on something like
> 
>   #!/bin/sh

Watch out for when xargs invokes do_something more than once and the `<'
is parsed by a different one than the `>'.  A `while read ...; do ...
done' would avoid that, but wouldn't like the NULs instead of LFs.

Cheers,


Ralph.

-
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/

[2.6 patch] sound/pci/ymfpci/ymfpci_main.c: remove dead code

[Adrian Bunk]

This patch removes some dead code found by the Coverity checker.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 sound/pci/ymfpci/ymfpci_main.c |   31 ---
 1 files changed, 8 insertions(+), 23 deletions(-)

--- linux-2.6.12-rc2-mm2-full/sound/pci/ymfpci/ymfpci_main.c.old
2005-04-09 22:22:16.0 +0200
+++ linux-2.6.12-rc2-mm2-full/sound/pci/ymfpci/ymfpci_main.c2005-04-09 
22:38:00.0 +0200
@@ -1418,44 +1418,40 @@
   .private_value = reg }
 
 static int snd_ymfpci_info_single(snd_kcontrol_t *kcontrol, 
snd_ctl_elem_info_t * uinfo)
 {
-   unsigned int mask = 1;
-
switch (kcontrol->private_value) {
case YDSXGR_SPDIFOUTCTRL: break;
case YDSXGR_SPDIFINCTRL: break;
default: return -EINVAL;
}
-   uinfo->type = mask == 1 ? SNDRV_CTL_ELEM_TYPE_BOOLEAN : 
SNDRV_CTL_ELEM_TYPE_INTEGER;
+   uinfo->type = SNDRV_CTL_ELEM_TYPE_BOOLEAN;
uinfo->count = 1;
uinfo->value.integer.min = 0;
-   uinfo->value.integer.max = mask;
+   uinfo->value.integer.max = 1;
return 0;
 }
 
 static int snd_ymfpci_get_single(snd_kcontrol_t * kcontrol, 
snd_ctl_elem_value_t * ucontrol)
 {
ymfpci_t *chip = snd_kcontrol_chip(kcontrol);
int reg = kcontrol->private_value;
-   unsigned int shift = 0, mask = 1, invert = 0;
+   unsigned int shift = 0, mask = 1;

switch (kcontrol->private_value) {
case YDSXGR_SPDIFOUTCTRL: break;
case YDSXGR_SPDIFINCTRL: break;
default: return -EINVAL;
}
ucontrol->value.integer.value[0] = (snd_ymfpci_readl(chip, reg) >> 
shift) & mask;
-   if (invert)
-   ucontrol->value.integer.value[0] = mask - 
ucontrol->value.integer.value[0];
return 0;
 }
 
 static int snd_ymfpci_put_single(snd_kcontrol_t * kcontrol, 
snd_ctl_elem_value_t * ucontrol)
 {
ymfpci_t *chip = snd_kcontrol_chip(kcontrol);
int reg = kcontrol->private_value;
-   unsigned int shift = 0, mask = 1, invert = 0;
+   unsigned int shift = 0, mask = 1;
int change;
unsigned int val, oval;

switch (kcontrol->private_value) {
@@ -1463,10 +1459,8 @@
case YDSXGR_SPDIFINCTRL: break;
default: return -EINVAL;
}
val = (ucontrol->value.integer.value[0] & mask);
-   if (invert)
-   val = mask - val;
val <<= shift;
spin_lock_irq(>reg_lock);
oval = snd_ymfpci_readl(chip, reg);
val = (oval & ~(mask << shift)) | val;
@@ -1484,24 +1478,23 @@
 
 static int snd_ymfpci_info_double(snd_kcontrol_t *kcontrol, 
snd_ctl_elem_info_t * uinfo)
 {
unsigned int reg = kcontrol->private_value;
-   unsigned int mask = 16383;
 
if (reg < 0x80 || reg >= 0xc0)
return -EINVAL;
-   uinfo->type = mask == 1 ? SNDRV_CTL_ELEM_TYPE_BOOLEAN : 
SNDRV_CTL_ELEM_TYPE_INTEGER;
+   uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
uinfo->count = 2;
uinfo->value.integer.min = 0;
-   uinfo->value.integer.max = mask;
+   uinfo->value.integer.max = 16383;
return 0;
 }
 
 static int snd_ymfpci_get_double(snd_kcontrol_t * kcontrol, 
snd_ctl_elem_value_t * ucontrol)
 {
ymfpci_t *chip = snd_kcontrol_chip(kcontrol);
unsigned int reg = kcontrol->private_value;
-   unsigned int shift_left = 0, shift_right = 16, mask = 16383, invert = 0;
+   unsigned int shift_left = 0, shift_right = 16, mask = 16383;
unsigned int val;

if (reg < 0x80 || reg >= 0xc0)
return -EINVAL;
@@ -1509,31 +1502,23 @@
val = snd_ymfpci_readl(chip, reg);
spin_unlock_irq(>reg_lock);
ucontrol->value.integer.value[0] = (val >> shift_left) & mask;
ucontrol->value.integer.value[1] = (val >> shift_right) & mask;
-   if (invert) {
-   ucontrol->value.integer.value[0] = mask - 
ucontrol->value.integer.value[0];
-   ucontrol->value.integer.value[1] = mask - 
ucontrol->value.integer.value[1];
-   }
return 0;
 }
 
 static int snd_ymfpci_put_double(snd_kcontrol_t * kcontrol, 
snd_ctl_elem_value_t * ucontrol)
 {
ymfpci_t *chip = snd_kcontrol_chip(kcontrol);
unsigned int reg = kcontrol->private_value;
-   unsigned int shift_left = 0, shift_right = 16, mask = 16383, invert = 0;
+   unsigned int shift_left = 0, shift_right = 16, mask = 16383;
int change;
unsigned int val1, val2, oval;

if (reg < 0x80 || reg >= 0xc0)
return -EINVAL;
val1 = ucontrol->value.integer.value[0] & mask;
val2 = ucontrol->value.integer.value[1] & mask;
-   if (invert) {
-   val1 = mask - val1;
-   val2 = mask - val2;
-   }
val1 <<= shift_left;
val2 <<= shift_right;
spin_lock_irq(>reg_lock);
oval = snd_ymfpci_readl(chip, reg);

-
To unsubscribe from this list: send the line 

[patch] MAINTAINERS: remove obsolete ACP/MWAVE MODEM entry

[Adrian Bunk]

Both maintainer email addresses are bouncing and the web address is no 
longer valid.

Seems to be a good time to remove the entry.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

--- linux-2.6.12-rc2-mm2-full/MAINTAINERS.old   2005-04-10 01:12:58.0 
+0200
+++ linux-2.6.12-rc2-mm2-full/MAINTAINERS   2005-04-10 01:13:14.0 
+0200
@@ -172,14 +172,6 @@
 W: http://www.stud.uni-karlsruhe.de/~uh1b/
 S: Maintained
 
-ACP/MWAVE MODEM
-P: Paul B Schroeder
-M: [EMAIL PROTECTED]
-P: Mike Sullivan
-M: [EMAIL PROTECTED]
-W: http://www.ibm.com/linux/ltc/
-S: Supported
-
 AACRAID SCSI RAID DRIVER
 P: Adaptec OEM Raid Solutions
 L: linux-scsi@vger.kernel.org

-
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: Status of new kernel.org servers

[H. Peter Anvin]

Andre Tomt wrote:
H. Peter Anvin wrote:
For those of you that are interested...

I kind of sort of miss the load and bandwidth statistics on the 
kernel.org front page. Did they just go boring now with sufficient 
hardware resources? :-)
No; the issue there is that with multiple servers we have to change the 
way they're generated and distributed.  Nathan Laredo is working on 
that, but it's so obviously not a high priority item.

-hpa
-
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/

[2.6 patch] drivers/scsi/sym53c416.c: fix a wrong check

[Adrian Bunk]

The Coverity checker found that this for loop was wrong.

This patch changes it to what seems to be intended.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

--- linux-2.6.12-rc2-mm2-full/drivers/scsi/sym53c416.c.old  2005-04-09 
22:16:04.0 +0200
+++ linux-2.6.12-rc2-mm2-full/drivers/scsi/sym53c416.c  2005-04-09 
22:16:28.0 +0200
@@ -803,19 +803,19 @@
 static int sym53c416_host_reset(Scsi_Cmnd *SCpnt)
 {
int base;
int scsi_id = -1;   
int i;
 
/* printk("sym53c416_reset\n"); */
base = SCpnt->device->host->io_port;
/* search scsi_id - fixme, we shouldnt need to iterate for this! */
-   for(i = 0; i < host_index && scsi_id != -1; i++)
+   for(i = 0; i < host_index && scsi_id == -1; i++)
if(hosts[i].base == base)
scsi_id = hosts[i].scsi_id;
outb(RESET_CHIP, base + COMMAND_REG);
outb(NOOP | PIO_MODE, base + COMMAND_REG);
outb(RESET_SCSI_BUS, base + COMMAND_REG);
sym53c416_init(base, scsi_id);
return SUCCESS;
 }
 

-
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: Kernel SCM saga..

[Linus Torvalds]

On Sat, 9 Apr 2005, David S. Miller wrote:
> 
> I understand the arguments for compression, but I hate it for one
> simple reason: recovery is more difficult when you corrupt some
> file in your repository.

Trust me, the way git does things, you'll have so much redundancy that 
you'll have to really _work_ at losing data.

That's the good news.

The bad news is that this is obviously why it does eat a lot of disk. 
Since it saves full-file commits, you're going to have a lot of 
(compressed) full files around.

Linus
-
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] sched: unlocked context-switches

[David S. Miller]

On Sat, 9 Apr 2005 00:15:37 -0700
David Mosberger <[EMAIL PROTECTED]> wrote:

> Yes, of course.  The deadlock was due to context-switching, not
> switch_mm() per se.  Hopefully someone else beats me to remembering
> the details before Monday.

Sparc64 has a deadlock because we hold mm->page_table_lock during
switch_mm().  I bet IA64 did something similar, as I remember it
had a very similar locking issue in this area.

So the deadlock was, we held the runqueue locks over switch_mm(),
switch_mm() spins on mm->page_table_lock, the cpu which does have
mm->page_table_lock tries to do a wakeup on the first cpu's runqueue.
Classic AB-BA deadlock.
-
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/

[2.6 patch] drivers/media/dvb/b2c2/skystar2.c: remove an impossible code path

[Adrian Bunk]

This patch removes an impossible code path found by the Coverity 
checker (look at the assignement in the first line of the context).

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/media/dvb/b2c2/skystar2.c |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.12-rc2-mm2-full/drivers/media/dvb/b2c2/skystar2.c.old 
2005-04-09 22:09:27.0 +0200
+++ linux-2.6.12-rc2-mm2-full/drivers/media/dvb/b2c2/skystar2.c 2005-04-09 
22:10:13.0 +0200
@@ -1358,49 +1358,49 @@ static int dma_init_dma(struct adapter *
subbuffers = 2;
 
subbufsize = (((adapter->dmaq1.buffer_size / 2) / 4) << 8) | 
subbuffers;
 
subbuf0 = adapter->dmaq1.bus_addr & 0xfffc;
 
subbuf1 = ((adapter->dmaq1.bus_addr + 
adapter->dmaq1.buffer_size / 2) & 0xfffc) | 1;
 
dprintk("%s: first subbuffer address = 0x%x\n", __FUNCTION__, 
subbuf0);
udelay(1000);
write_reg_dw(adapter, 0x000, subbuf0);
 
dprintk("%s: subbuffer size = 0x%x\n", __FUNCTION__, 
(subbufsize >> 8) * 4);
udelay(1000);
write_reg_dw(adapter, 0x004, subbufsize);
 
dprintk("%s: second subbuffer address = 0x%x\n", __FUNCTION__, 
subbuf1);
udelay(1000);
write_reg_dw(adapter, 0x00c, subbuf1);
 
dprintk("%s: counter = 0x%x\n", __FUNCTION__, 
adapter->dmaq1.bus_addr & 0xfffc);
write_reg_dw(adapter, 0x008, adapter->dmaq1.bus_addr & 
0xfffc);
udelay(1000);
 
-   dma_enable_disable_irq(adapter, 0, 1, subbuffers ? 1 : 0);
+   dma_enable_disable_irq(adapter, 0, 1, 1);
 
irq_dma_enable_disable_irq(adapter, 1);
 
sram_set_media_dest(adapter, 1);
sram_set_net_dest(adapter, 1);
sram_set_cai_dest(adapter, 2);
sram_set_cao_dest(adapter, 2);
}
 
if (dma_channel == 1) {
dprintk("%s: Initializing DMA2 channel\n", __FUNCTION__);
 
subbuffers = 2;
 
subbufsize = (((adapter->dmaq2.buffer_size / 2) / 4) << 8) | 
subbuffers;
 
subbuf0 = adapter->dmaq2.bus_addr & 0xfffc;
 
subbuf1 = ((adapter->dmaq2.bus_addr + 
adapter->dmaq2.buffer_size / 2) & 0xfffc) | 1;
 
dprintk("%s: first subbuffer address = 0x%x\n", __FUNCTION__, 
subbuf0);
udelay(1000);
write_reg_dw(adapter, 0x010, subbuf0);
 

-
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/

[2.6 patch] drivers/scsi/qla2xxx/qla_os.c: remove dead code

[Adrian Bunk]

This patch removes some dead code found by the Coverity checker (rval 
can't be FAILED at the time of this check).

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

--- linux-2.6.12-rc2-mm2-full/drivers/scsi/qla2xxx/qla_os.c.old 2005-04-09 
22:24:09.0 +0200
+++ linux-2.6.12-rc2-mm2-full/drivers/scsi/qla2xxx/qla_os.c 2005-04-09 
22:49:01.0 +0200
@@ -1649,14 +1649,11 @@ qla2xxx_eh_host_reset(struct scsi_cmnd *
clear_bit(ABORT_ISP_ACTIVE, >dpc_flags);
 
spin_lock_irq(ha->host->host_lock);
-   if (rval == FAILED)
-   goto out;
 
/* Waiting for our command in done_queue to be returned to OS.*/
if (!qla2x00_eh_wait_for_pending_commands(ha))
rval = FAILED;
 
- out:
qla_printk(KERN_INFO, ha, "%s: reset %s\n", __func__,
(rval == FAILED) ? "failed" : "succeded");
 

-
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/

$B!y!!(BNEW$B!!(BOPEN$B!!!y(B

[info]

$B!!!z!y!z!!$D$$$K#O#P#E#N!*!!!z!y!z(B

$B4JC1A`:n$G4JC1EPO?!*(B

$B!!??7u$J=P2q$$$O$3$3$+$i(B

$B!!(B  $B=i$a$F$NJ}$OL5NA%(%s%H%j!<$+$i$I$&$>(B



  $B(Bhttp://www.getluck.net/



$B"(GIhttp://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6 patch] drivers/char/mwave/tp3780i.c: remove dead code

[Adrian Bunk]

This patch removes some dead code found by the Coverity checker.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/char/mwave/tp3780i.c |6 +-
 1 files changed, 1 insertion(+), 5 deletions(-)

--- linux-2.6.12-rc2-mm2-full/drivers/char/mwave/tp3780i.c.old  2005-04-09 
21:41:37.0 +0200
+++ linux-2.6.12-rc2-mm2-full/drivers/char/mwave/tp3780i.c  2005-04-09 
21:42:32.0 +0200
@@ -283,13 +283,13 @@
 
 
 
 int tp3780I_EnableDSP(THINKPAD_BD_DATA * pBDData)
 {
DSP_3780I_CONFIG_SETTINGS *pSettings = >rDspSettings;
-   BOOLEAN bDSPPoweredUp = FALSE, bDSPEnabled = FALSE, bInterruptAllocated 
= FALSE;
+   BOOLEAN bDSPPoweredUp = FALSE, bInterruptAllocated = FALSE;
 
PRINTK_2(TRACE_TP3780I, "tp3780i::tp3780I_EnableDSP entry pBDData 
%p\n", pBDData);
 
if (pBDData->bDSPEnabled) {
PRINTK_ERROR(KERN_ERR_MWAVE "tp3780i::tp3780I_EnableDSP: Error: 
DSP already enabled!\n");
goto exit_cleanup;
@@ -388,28 +388,24 @@
bDSPPoweredUp = TRUE;
}
 
if (dsp3780I_EnableDSP(pSettings, s_ausThinkpadIrqToField, 
s_ausThinkpadDmaToField)) {
PRINTK_ERROR("tp3780i::tp3780I_EnableDSP: Error: 
dsp7880I_EnableDSP() failed\n");
goto exit_cleanup;
-   } else {
-   bDSPEnabled = TRUE;
}
 
EnableSRAM(pBDData);
 
pBDData->bDSPEnabled = TRUE;
 
PRINTK_1(TRACE_TP3780I, "tp3780i::tp3780I_EnableDSP exit\n");
 
return 0;
 
 exit_cleanup:
PRINTK_ERROR("tp3780i::tp3780I_EnableDSP: Cleaning up\n");
-   if (bDSPEnabled)
-   dsp3780I_DisableDSP(pSettings);
if (bDSPPoweredUp)
smapi_set_DSP_power_state(FALSE);
if (bInterruptAllocated) {
free_irq(pSettings->usDspIrq, NULL);
pSettings->bInterruptClaimed = FALSE;
}

-
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/

[2.6 patch] drivers/video/matrox/matroxfb_misc.c: remove dead code

[Adrian Bunk]

This patch removes some obviously dead code found by the Coverity 
checker.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

--- linux-2.6.12-rc2-mm2-full/drivers/video/matrox/matroxfb_misc.c.old  
2005-04-09 21:40:17.0 +0200
+++ linux-2.6.12-rc2-mm2-full/drivers/video/matrox/matroxfb_misc.c  
2005-04-09 21:40:47.0 +0200
@@ -195,14 +195,11 @@ int matroxfb_vgaHWinit(WPMINFO struct my
fwidth = 8;
 
DBG(__FUNCTION__)
 
hw->SEQ[0] = 0x00;
-   if (fwidth == 9)
-   hw->SEQ[1] = 0x00;
-   else
-   hw->SEQ[1] = 0x01;  /* or 0x09 */
+   hw->SEQ[1] = 0x01;  /* or 0x09 */
hw->SEQ[2] = 0x0F;  /* bitplanes */
hw->SEQ[3] = 0x00;
hw->SEQ[4] = 0x0E;
/* CRTC 0..7, 9, 16..19, 21, 22 are reprogrammed by Matrox Millennium 
code... Hope that by MGA1064 too */
if (m->dblscan) {

-
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/

[2.6 patch] drivers/net/ewrk3.c: remove dead code

[Adrian Bunk]

This patch removes some obviously dead code found by the Coverity 
checker.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/net/ewrk3.c |   12 +++-
 1 files changed, 3 insertions(+), 9 deletions(-)

--- linux-2.6.12-rc2-mm2-full/drivers/net/ewrk3.c.old   2005-04-09 
22:03:49.0 +0200
+++ linux-2.6.12-rc2-mm2-full/drivers/net/ewrk3.c   2005-04-09 
22:04:15.0 +0200
@@ -1308,15 +1308,9 @@ static int __init eisa_probe(struct net_
if (ioaddr < 0x1000)
goto out;
 
-   if (ioaddr == 0) {  /* Autoprobing */
-   iobase = EISA_SLOT_INC; /* Get the first slot address */
-   i = 1;
-   maxSlots = MAX_EISA_SLOTS;
-   } else {/* Probe a specific location */
-   iobase = ioaddr;
-   i = (ioaddr >> 12);
-   maxSlots = i + 1;
-   }
+   iobase = ioaddr;
+   i = (ioaddr >> 12);
+   maxSlots = i + 1;
 
for (i = 1; (i < maxSlots) && (dev != NULL); i++, iobase += 
EISA_SLOT_INC) {
if (EISA_signature(name, EISA_ID) == 0) {

-
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/

[2.6 patch] drivers/block/sx8.c: remove unused code

[Adrian Bunk]

Is it planned to ever #define IF_64BIT_DMA_IS_POSSIBLE ?

If not, the patch below removes this currently completely unused code.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/block/sx8.c |   30 ++
 1 files changed, 6 insertions(+), 24 deletions(-)

--- linux-2.6.12-rc2-mm2-full/drivers/block/sx8.c.old   2005-04-09 
21:51:31.0 +0200
+++ linux-2.6.12-rc2-mm2-full/drivers/block/sx8.c   2005-04-09 
21:52:46.0 +0200
@@ -176,7 +176,6 @@ enum {
FL_NON_RAID = FW_VER_NON_RAID,
FL_4PORT= FW_VER_4PORT,
FL_FW_VER_MASK  = (FW_VER_NON_RAID | FW_VER_4PORT),
-   FL_DAC  = (1 << 16),
FL_DYN_MAJOR= (1 << 17),
 };
 
@@ -1565,7 +1564,6 @@ static int carm_init_one (struct pci_dev
 {
static unsigned int printed_version;
struct carm_host *host;
-   unsigned int pci_dac;
int rc;
request_queue_t *q;
unsigned int i;
@@ -1581,28 +1579,12 @@ static int carm_init_one (struct pci_dev
if (rc)
goto err_out;
 
-#if IF_64BIT_DMA_IS_POSSIBLE /* g... */
-   rc = pci_set_dma_mask(pdev, 0xULL);
-   if (!rc) {
-   rc = pci_set_consistent_dma_mask(pdev, 0xULL);
-   if (rc) {
-   printk(KERN_ERR DRV_NAME "(%s): consistent DMA mask 
failure\n",
-   pci_name(pdev));
-   goto err_out_regions;
-   }
-   pci_dac = 1;
-   } else {
-#endif
-   rc = pci_set_dma_mask(pdev, 0xULL);
-   if (rc) {
-   printk(KERN_ERR DRV_NAME "(%s): DMA mask failure\n",
-   pci_name(pdev));
-   goto err_out_regions;
-   }
-   pci_dac = 0;
-#if IF_64BIT_DMA_IS_POSSIBLE /* g... */
+   rc = pci_set_dma_mask(pdev, 0xULL);
+   if (rc) {
+   printk(KERN_ERR DRV_NAME "(%s): DMA mask failure\n",
+   pci_name(pdev));
+   goto err_out_regions;
}
-#endif
 
host = kmalloc(sizeof(*host), GFP_KERNEL);
if (!host) {
@@ -1614,7 +1596,7 @@ static int carm_init_one (struct pci_dev
 
memset(host, 0, sizeof(*host));
host->pdev = pdev;
-   host->flags = pci_dac ? FL_DAC : 0;
+   host->flags = 0;
spin_lock_init(>lock);
INIT_WORK(>fsm_task, carm_fsm_task, host);
init_MUTEX_LOCKED(>probe_sem);

-
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: Kernel SCM saga..

[David S. Miller]

On Fri, 8 Apr 2005 22:45:18 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:

> Also, I don't want people editing repostitory files by hand. Sure, the 
> sha1 catches it, but still... I'd rather force the low-level ops to use 
> the proper helper routines. Which is why it's a raw zlib compressed blob, 
> not a gzipped file.

I understand the arguments for compression, but I hate it for one
simple reason: recovery is more difficult when you corrupt some
file in your repository.

It's happened to me more than once and I did lose data.

Without compression, I might be able to recover if something
causes a block of zeros to be written to the middle of some
repository file.  With compression, you pretty much just lose.
-
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] sched: unlocked context-switches

[David S. Miller]

On Sat, 09 Apr 2005 19:22:23 +1000
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:

> ppc64 already has a local_irq_save/restore in switch_to, around the low
> level asm bits, so it should be fine.

Sparc64 essentially does as well.  In fact, it uses an IRQ disable
which is stronger  than local_irq_save in that it disables reception
of CPU cross-calls as well.

Re: [RFC,PATCH 3/4] Change synchronize_kernel to _rcu and _sched

[Francois Romieu]

Manfred Spraul <[EMAIL PROTECTED]> :
[...]
> I always thought that all callers of dev->hard_start_xmit() acquire
> dev->xmit_lock before calling hard_start_xmit().
> 
> Is that assumption wrong? I think I even rely on that in one of my
> drivers.

Afaik, no, it is right.

This part of the r8169 driver handles the window starting where qdisc_run()
tests netif_queue_stopped() to the spin_trylock(>xmit_lock) in
qdisc_restart: the lock is not taken and dev->hard_start_xmit() will happen
in the near future ("near" or "preempt safe near" is not relevant here).
The driver must wait for the late newcomer to do its whole work before
it can release the Tx ring, whence the former synchronize_kernel().

r8169_down() looks a bit baroque because it can race with the irq handler
or dev->poll() or the recovery timer and none of those spin_locks either.

I may have missed something though. Feel free to educate.

--
Ueimor
-
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/

Status of new kernel.org servers

[H. Peter Anvin]

For those of you that are interested...

The second new kernel.org server, named, ironically enough,
zeus1.kernel.org went into the racks and, shortly thereafter, into
production Friday.  The only service that isn't served from both
servers at this time is mirrors.kernel.org for the simple reason that
it's still syncing on zeus1; it will probably be turned on early next
week.

As a consequence, all kernel.org services are now round-robin between
two hosts.  You can also hit a specific host by appending a digit,
e.g. ftp1.kernel.org, or mirrors2.kernel.org.

When one server is offline, we'll change the round-robin names to only
point to the one host that is in operation.

As some of you noticed, there was a problem early on which made
uploads lag behind; it has now been corrected and uploads should be
significantly faster than they have been in a long time.

As usual, please report problems to [EMAIL PROTECTED]  As far as we
know, the transition problems have been taken care of and all should
be well.

-hpa

P.S. Again, thanks to HP for the new servers and to ISC for hosting
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: Kernel SCM saga..

[Florian Weimer]

* David Lang:

>> Databases supporting replication are called high end. You forgot
>> the cats dance around the network this issue involves.
>
> And Postgres (which is Free in all senses of the word) is high end by this 
> definition.

I'm not aware of *any* DBMS, commercial or not, which can perform
meaningful multi-master replication on tables which mainly consist of
text files as records.  All you can get is single-master replication
(which is well-understood), or some rather scary stuff which involves
throwing away updates, or taking extrema or averages (even automatic
3-way merges aren't available).
-
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: PROBLEM: CompactFlash mount Oops

[Dominik Brodowski]

Hi,

The problem seems to be
> cs: pcmcia_socket0: voltage interrogation timed out.

Can you try passing the parameter

setup_delay=50

to the module named "pcmcia", please?

Dominik
-
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: more git updates..

[Paul Jackson]

Linus wrote:
> the NUL-termination makes this really easy to use even in shell

grumble ...

> I still use the old tools I learnt to use fifteen years ago

new comer ;)

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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/

Unified changelogs for parsing by scripts

[Zack Brown]

Hi Linus, Andrew, Marcelo, Greg, Chris, and folks,

Since the SCM situation is changing, I thought I'd put in a word for those of us
who like parsing changelogs via scripts. Hopefully the loss of BitKeeper will
not involve a loss of detail in the changelogs as well. Maybe the changelogs
could even be improved now.

I parse the 2.6 and 2.4 changelogs, including all -pre, -rc, and w.x.y.z
kernels, and I find that there's a wide variety of formatting that's been
used over the past few years. This makes it impossible to produce a working
web application for outside consumption, because I can never tell when the
whole thing will break because of some new anomaly.

So this email is to make some of the following suggestions for future changelog
formats:

1) the date of the particular entry, the date of the kernel release, the full
name (if available) of the author of the patch, the email of the author of
the patch, and the changelog entry itself should all have specific, easily
parsable locations. The start of each entry should also be completely
unambiguous.

2) there should be no extraneous information (i.e. nothing other than changelog
entries) in the file. (no version number header at the top of the file, no
multiple changelogs for multiple kernel releases in the same file, no dashed
lines as line separators, etc). Or at least, extraneous data should be easily
siftable.

3) the changelog system for the kernel should standardize on what information
it contains, and where and how this information is delineated. Currently
for example, the 2.4 changelog is against the previous full release, rather
than the most recent -rc release; while the 2.6 changelog is against the
most recent -rc release. Whenever a new 2.4 kernel comes out, I have to extract
the -rc changelog information from it, then go in by hand and date them all
by looking at mailing list archives. There are also tons of special cases,
especially in the earlier days of BitKeeper, oddly formatted entries, entries
with some kinds of information in one part of the file, and different
information in another. It's a mess.

4) the locations of changelogs on kernel.org should be completely predictable
programmatically.

5) when the format of changelogs changes, all previous changelogs should be
regenerated in the new format. There should be a mailing list for people
who would like to know in advance when the changelog format will change,
so they can update their web page CGI and not crash and burn.

All I'm really asking is that the various kernel maintainers recognize
that the issue exists, and take the opportunity, while changing version
control systems, to come up with a clean solution for those of us tracking
developments automatically. Or trying to.

Be well,
Zack

-- 
Zack Brown

-
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: bdflush/rpciod high CPU utilization, profile does not make sense

[Trond Myklebust]

lau den 09.04.2005 Klokka 23:35 (+0200) skreiv Jakob Oestergaard:

> 2.6.11.6: (dual PIII 1GHz, 2G RAM, Intel e1000)
> 
>  File   Block  Num  Seq ReadRand Read   Seq Write  Rand Write
>   DirSize   Size   Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%)
> --- -- --- --- --- --- --- ---
>. 2000   40961  38.34 18.8% 19.61 6.77% 22.53 23.4% 6.947 15.6%
>. 2000   40962  52.82 29.0% 24.42 9.37% 24.20 27.0% 7.755 16.7%
>. 2000   40964  62.48 34.8% 33.65 17.0% 24.73 27.6% 8.027 15.4%
> 
> 
> 44MiB/sec for 2.4 versus 22MiB/sec for 2.6 - any suggestions as to how
> this could be improved?

What happened to the retransmission rates when you changed to TCP?

Note that on TCP (besides bumping the value for timeo) I would also
recommend using a full 32k r/wsize instead of 4k (if the network is of
decent quality, I'd recommend 32k for UDP too).

The other tweak you can apply for TCP is to bump the value
for /proc/sys/sunrpc/tcp_slot_table_entries. That will allow you to have
several more RPC requests in flight (although that will also tie up more
threads on the server).

Don't forget that you need to unmount then mount again after making
these changes (-oremount won't suffice).

Cheers,
  Trond

-- 
Trond Myklebust <[EMAIL PROTECTED]>

-
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: bdflush/rpciod high CPU utilization, profile does not make sense

[Jakob Oestergaard]

On Thu, Apr 07, 2005 at 12:17:51PM -0400, Trond Myklebust wrote:
> to den 07.04.2005 Klokka 17:38 (+0200) skreiv Jakob Oestergaard:
> 
> > I tweaked the VM a bit, put the following in /etc/sysctl.conf:
> >  vm.dirty_writeback_centisecs=100
> >  vm.dirty_expire_centisecs=200
> > 
> > The defaults are 500 and 3000 respectively...
> > 
> > This improved things a lot; the client is now "almost not very laggy",
> > and load stays in the saner 1-2 range.
> 
> OK. That hints at what is causing the latencies on the server: I'll bet
> it is the fact that the page reclaim code tries to be clever, and uses
> NFSv3 STABLE writes in order to be able to free up the dirty pages
> immediately. Could you try the following patch, and see if that makes a
> difference too?

The patch alone without the tweaked VM settings doesn't cure the lag - I
think it's better than without the patch (I can actually type this mail
with a large copy running). With the tweaked VM settings too, it's
pretty good - still a little lag, but not enough to really make it
annoying.

Performance is pretty much the same as before (copying an 8GiB file with
15-16MiB/sec - about half the performance of what I get locally on the
file server).

Something that worries me;  It seems that 2.4.25 is a lot faster as NFS
client than 2.6.11.6, most notably on writes - see the following
tiobench results (2000 KiB file, tests with 1, 2 and 4 threads) up
against the same NFS server:

2.4.25:  (dual athlon MP 1.4GHz, 1G RAM, Intel e1000)

 File   Block  Num  Seq ReadRand Read   Seq Write  Rand Write
  DirSize   Size   Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%)
--- -- --- --- --- --- --- ---
   . 2000   40961  58.87 54.9% 5.615 5.03% 44.40 44.2% 4.534 8.41%
   . 2000   40962  56.98 58.3% 6.926 6.64% 41.61 58.0% 4.462 10.8%
   . 2000   40964  53.90 59.0% 7.764 9.44% 39.85 61.5% 4.256 10.8%


2.6.11.6: (dual PIII 1GHz, 2G RAM, Intel e1000)

 File   Block  Num  Seq ReadRand Read   Seq Write  Rand Write
  DirSize   Size   Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%)
--- -- --- --- --- --- --- ---
   . 2000   40961  38.34 18.8% 19.61 6.77% 22.53 23.4% 6.947 15.6%
   . 2000   40962  52.82 29.0% 24.42 9.37% 24.20 27.0% 7.755 16.7%
   . 2000   40964  62.48 34.8% 33.65 17.0% 24.73 27.6% 8.027 15.4%


44MiB/sec for 2.4 versus 22MiB/sec for 2.6 - any suggestions as to how
this could be improved?

(note; the write performance doesn't change notably with VM tuning nor
with the one-liner change that Trond suggested)

-- 

 / jakob

-
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: more git updates..

[Linus Torvalds]

On Sat, 9 Apr 2005, Linus Torvalds wrote:
> 
> I suspect that I have to change the file format. Maybe make the "tree" 
> object a two-level thing, and have a "directory" object.
> 
> Then a "tree" object would point to a "directory" object, which would in
> turn point to the individual files (and other "directory" objects, of
> course). That way a commit that only changes a few files will only need to
> create a few new "directory" objects, instead of creating one huge "tree"
> object.

Actually, I guess I wouldn't have to change the format. I could just 
extend the existing "tree" object to be able to point to other trees, and 
that's it.

The downside of that is that then a tree wouldn't have a canonical format 
any more: you could have two trees that have the exact same content, but 
they'd haev different names. They should obviously merge very easily (and 
thus you could create a new merge that _does_ have a common name), but 
it's ugly.

I'll have to think about it. It's good to notice these issues early, this 
was the first time I had actually tried to check in a kernel-sized tree 
for real.

Linus
-
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: more git updates..

[Linus Torvalds]

On Sat, 9 Apr 2005, Petr Baudis wrote:
> 
> > Also, I wrote the "diff-tree" thing I talked about: 
> ..snip..
> 
> Hmm, I wonder, is this better done in C instead of a simple shell
> script, like my gitdiff.sh?

With 17,000 files in the kernel, and most commits just changing a small 
number of them, I actually think "diff-tree" matters. You use "join" 
(which is quite reasonable), but let's put it this way: just the list of 
files in the current kernel is about half a megabyte of data. Ie your 
temporary files that you use in the "ls-tree + ls-tree + join" is actually 
going to be quite sizeable.

My goal here is that the speed of "git" really should be almost totally
independent of the size of the project. You clearly cannot avoid _some_ 
size-dependency: my "diff-tree" clearly also has to work through the same 
1MB of data, but I think it's worth making the constant factor be as small 
as humanly possible.

I just tried checking in a kernel tree tar-file, and the initial checkin 
(which is allt he compression and the sha1 calculations for every single 
file) took about 1:35 (minutes, not hours ;).

Doing a commit (trivial change to the top-level Makefile) and then doing a 
"treediff" between those two things took 0.05 seconds using my C thing. Ie 
we're talking so fast that we really don't care.

Doing a "show-diff" takes 0.15 secs or so (that's all the "stat" calls), 
and now that I test it out I realize that the most expensive operation is 
actually _writing_ the "index" file out. These are the two most expensive 
steps:

[EMAIL PROTECTED]:~/lx-test/linux-2.6.12-rc2> time update-cache Makefile

real0m0.283s
user0m0.171s
sys 0m0.113s


[EMAIL PROTECTED]:~/lx-test/linux-2.6.12-rc2> time write-tree
5ca21c9d808fa4bee1eb6948a59dfb9c7d73f36a

real0m0.441s
user0m0.354s
sys 0m0.087s

ie with the current infrastructure it looks like I can do a "patch + 
commit" in less than one second on the kernel, and 0.75 secs of that is 
because the "tree" file actually grows pretty large:

cat-file tree 5ca21c9d808fa4bee1eb6948a59dfb9c7d73f36a | wc -c 

says that the uncompressed tree-file is 950,874 bytes. Compressing it 
means that the archival version of it is "just" 462,546 bytes, but this is 
really the part that is going to eat _tons_ of disk-space.

In other words, each "commit" file is very small and cheap, but since 
almost every commit will also imply a totally new tree-file, "git" is 
going to have an overhead of half a megabyte per commit. Oops.

Damn, that's painful. I suspect I will have to change the format somehow.

One option (which I haven't tested yet) is that since the tree-file is 
already sorted, I could always write it out with the common subdirectory 
part "collapsed", ie instead of writing

...
include/asm-i386/mach-default/bios_ebda.h
include/asm-i386/mach-default/do_timer.h
...

I'd write just

...
///bios_ebda.h
///do_timer.h
...

since the directory names are implied by the predecessor.

However, that doesn't help with the 20-byte sha1 associated with each
file, which is also obviously uncompressible, so with 17,000+ files, we
have a minimum overhead of abotu 350kB per tree-file.

So even if I did the pathname compression, it wouldn't help all that much.  
I'd only be removing the only part of the file that _is_ very
compressible, and I'd probably end up with something that isn't all that
far away from the 450kB+ it is now.

I suspect that I have to change the file format. Maybe make the "tree" 
object a two-level thing, and have a "directory" object.

Then a "tree" object would point to a "directory" object, which would in
turn point to the individual files (and other "directory" objects, of
course). That way a commit that only changes a few files will only need to
create a few new "directory" objects, instead of creating one huge "tree"
object.

Sadly, that will make "tree-diff" potentially more expensive. On the other
hand, maybe not: it will also speed it _up_, since directories that are
totally shared will be trivially seen as such and need no further
operation.

Thougths? That would break the current repository formats, and I'd have to 
create a converter thing (which shouldn't be that bad, of course).

I don't have to do it right now. In fact, I'd almost prefer for the
current thing to become good enough that it's not painful to work with,
since right now I'm using it to develop itself. Then I can convert the
format with an automated script later, before I actually start working on
the kernel...

> BTW, do we care about changed modes? If so, they should probably have
> their place in the diff-tree output.

They're there. If you want to ignore them, you can just notice that the 
sha1 matches between two lines, and then you don't even have to diff them.

Linus
-
To unsubscribe from this 

Re: memory_barrier

[Roland Dreier]

Bart> Hi, Is there any reason why __memory_barrier() is still
Bart> referenced in the kernel source?

Bart> grep -r memory_barrier gave the following back, which at
Bart> first seems to suggest barrier() is defined using some
Bart> phantom __memory_barrier(), quite deceiving...

Notice that it's used in  -- the Intel
compiler has an intrinsic called __memory_barrier().  So the
definition of barrier() using this intrinsic is entirely correct and
appropriate.

 - R.
-
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: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Raul Miller]

> > It's impossible to treat patents consistently.

On Sat, Apr 09, 2005 at 04:38:15PM +0200, Adrian Bunk wrote:
> Even RedHat with a stronger financial background than Debian considered 
> the MP3 patents being serious enough to remove MP3 support.

It's silly to treat financial risk as being a one dimensional quantity.

It could easily be that Red Hat decided that the mp3 patent owners would
be going after people with deep pockets.  If this is the risk model,
Red Hat's risk would be much much higher than Debian's.

> Note that this is a respose to Josselin's statement:
> 
< When there are several possible interpretations, you have to pick up the
< more conservative one, as it's not up to us to make the interpretation,
< but to a court.

Sure, if you have several plausible interpretations, you pick the one
you feel is likely to be the most important, and if all of them seem
likely you pick the one that seems worst.

But, ultimately, you can't treat software patents consistently.
There's no reasonable way to do so.

> It's simply silly to be extremely picky on copyright issues while being 
> extremely liberal on patent issues - the risk of a Debian distributor 
> being sued for patent violations (no matter how the lawsuit might end) 
> is definitely present.

Anything to do with software patents is silly.  Being liberal about
software patents is silly.  Being conservative about software patents
is silly.

Copyright, while far from perfect, can at least be reasoned about.

> > As for this particular patent, I'm not really sure what's being patented.
> >...

> Which one of the 23 patents they list do you call "this particular
> patent"?

What makes you think I'm sure about what's being patented in 22 of
those patents?

I should probably have said "As for patent claims applying to mp3,
...", but the issue is thorny enough that even that might not have been
accurate enough.

But, treating "this particular patent" as a meta-syntactic variable
should be adequate for you to understand what I was saying.

Bottom line, though: softare patents generally make very little sense.

-- 
Raul
-
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 to fix bashism

[David Weinehall]

On Fri, Apr 08, 2005 at 11:11:38PM +0159, Han Boetes wrote:
> Hi,
> 
> This patch fixes a three bashisms in
> scripts/gen_initramfs_list.sh;
> 
> I'm not sure of the intention of the second change (local
> name=...). So it's very well possible that:
> 
> +   local name="${location%/$srcdir}"
> 
> is more appropriate.

This patch is not going to work; local is a bash:ism too, hence this
will fail when /bin/sh is a more strict POSIX-shell.  However,
it is quite likely that the use of local is merely due to the
(totally correct) instinct of always limiting the scope of variables.
Most scripts that I've POSIX-fixed so far could just have the local
removed with no bad effects.

> --- scripts/gen_initramfs_list.sh.orig2005-03-27 14:53:15.628883408 
> +0200
> +++ scripts/gen_initramfs_list.sh 2005-03-27 15:12:20.093898280 +0200
> @@ -1,4 +1,7 @@
> -#!/bin/bash
> +#!/bin/sh
> +
> +# script is sourced, the shebang is ignored.
> +
>  # Copyright (C) Martin Schlemmer <[EMAIL PROTECTED]>
>  # Released under the terms of the GNU GPL
>  #
> @@ -56,9 +59,9 @@
>  
>  parse() {
>   local location="$1"
> - local name="${location/${srcdir}//}"
> + local name="${location#$srcdir/}"
>   # change '//' into '/'
> - name="${name//\/\///}"
> + name=`echo $name|sed -e 's|//|/|g'`

Using $(...) instead of `...` helps readability quite a lot for
things like this...

[snip]


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
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: more git updates..

[Petr Baudis]

Hello,

Dear diary, on Sat, Apr 09, 2005 at 09:45:52PM CEST, I got a letter
where Linus Torvalds <[EMAIL PROTECTED]> told me that...
> The good news is, the data structures/indexes haven't changed, but many of 
> the tools to interface with them have new (and improved!) semantics:
> 
> In particular, I changed how "read-tree" works, so that it now mirrors
> "write-tree", in that instead of actually changing the working directory,
> it only updates the index file (aka "current directory cache" file from
> the tree).
> 
> To actually change the working directory, you'd first get the index file
> setup, and then you do a "checkout-cache -a" to update the files in your
> working directory with the files from the sha1 database.

that's great. I was planning to do something with this since currently
it really annoyed me. I think I will like this, even though I didn't
look at the code itself yet (just on my way).

> Also, I wrote the "diff-tree" thing I talked about: 
..snip..

Hmm, I wonder, is this better done in C instead of a simple shell
script, like my gitdiff.sh? I'd say it is more flexible and probably
hardly performance-critical to have this scripted, and not difficult at
all provided you have ls-tree. But maybe I'm just too fond of my
script... ;-) (Ok, there's some trouble when you want to have newlines
and spaces in file names, and join appears to be awfully ignorant about
this... :[ )

BTW, do we care about changed modes? If so, they should probably have
their place in the diff-tree output.

BTW#2, I hope you will merge my ls-tree anyway, even though there is no
user for it currently... I should quickly figure out some. :-)

> Can you guys re-send the scripts you wrote? They probably need some 
> updating for the new semantics. Sorry about that ;(

I'll try to merge ASAP.

-- 
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
98% of the time I am right. Why worry about the other 3%.
-
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: more git updates..

[Linus Torvalds]

On Sat, 9 Apr 2005, Linus Torvalds wrote:
> 
> To actually change the working directory, you'd first get the index file
> setup, and then you do a "checkout-cache -a" to update the files in your
> working directory with the files from the sha1 database.

Btw, this will not overwrite any old files, so if you have an old version 
of something, you'd need to do "checkout-cache -f -a" (and order matters: 
the "-f" must come first). This time I actually have a big comment at the 
top of the checkout-cache.c file trying to explain the logic.

Linus
-
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/

more git updates..

[Linus Torvalds]

Sorry guys,
 several of you have sent me small fixes and scripts to "git", but I've 
been busy on breaking/changing the core infrastructure, so I didn't get 
around to looking at the scripts yet.

The good news is, the data structures/indexes haven't changed, but many of 
the tools to interface with them have new (and improved!) semantics:

In particular, I changed how "read-tree" works, so that it now mirrors
"write-tree", in that instead of actually changing the working directory,
it only updates the index file (aka "current directory cache" file from
the tree).

To actually change the working directory, you'd first get the index file
setup, and then you do a "checkout-cache -a" to update the files in your
working directory with the files from the sha1 database.

Also, I wrote the "diff-tree" thing I talked about: 

[EMAIL PROTECTED]:~/git> ./diff-tree 
8fd07d4b7778cd0233ea0a17acd3fe9d710af035 
8c6d29d6a496d12f1c224db945c0c56fd60ce941 | tr '\0' '\n'
<100664 4870bcf91f8666fc788b07578fb7473eda795587 Makefile
>100664 5493a649bb33b9264e8ed26cc1f832989a307d3b Makefile
<100664 9e1bee21e17c134a2fb008db62679048fc819528 cache.h
>100664 56ef561e590fd99e938bd47fd1f2c7ed46126ff0 cache.h
<100664 fd690acc02ef9c06d7c4c3541f69b10ca4b4f8c9 cat-file.c
>100664 6e6d89291ced17a406e64b97fe8bb96a22eefc9d cat-file.c
+100664 fd00e5603dcc4a93acceda0b8cb914fabc8645d5 checkout-cache.c
<100664 a4a8c3d9ef0c4cc6c82b96b5d1a91ac6d3bed466 commit-tree.c
>100664 236ceb7646e3f5d110fd83f815b82e94cc5b2927 commit-tree.c
+100664 01c92f2620a8e13e7cb7fd98ee644c6b65eeccb7 fsck-cache.c
<100664 0eaa053919e0cc400ab9bc40d9272360117e6978 init-db.c
>100664 815743e92dad7e451c65bab01448ee8ae9deeb56 init-db.c
<100664 e7bfaadd5d2331123663a8f14a26604a3cdcb678 read-cache.c
>100664 71d0cb6fe9b7ff79e3b2c5a61e288ac9f62b39dc read-cache.c
<100664 ec0f167a6a505659e5af6911c97f465506534c34 read-tree.c
>100664 f5c50ba79d02f002b9675fd8f129fa388e3282c6 read-tree.c
<100664 00a29c403e751c2a2a61eb24fa2249c8956d1c80 show-diff.c
>100664 b963dd738989bc92bf02352bbedad13a74e66a7d show-diff.c
<100664 aff074c63ac827801a7d02ff92781365957f1430 update-cache.c
>100664 3a672397164d5ff27a19a6888b578af96824ede7 update-cache.c
<100664 7abeeba116b2b251c12ae32c7b38cb048199b574 write-tree.c
>100664 9525c6fc975888a394477339db86216cd5bd5d7c write-tree.c

(ie the output of "diff-tree" has the same NUL-termination, but if you 
insist on getting ASCII output, you can just use "tr" to change the NUL 
into a NL).

The format of the "diff-tree" output is that the first character is "-"  
for "remove file", "+" for "add file" and "<"/">" for "change file" (where
the "<" shows the old state, and ">" shows the new state).

Btw, the NUL-termination makes this really easy to use even in shell
scripts, ie you can do

diff-tree   | xargs -0 do_something

and you'll get each line as one nice argument to your "do_something"  
script. So a do_diff could be based on something like

#!/bin/sh
while [ "$1" != "" ]; do
filename="$(echo $1 | cut -d' ' -f3-)"
first_sha="$(echo $1 | cut -d' ' -f2)"
second_sha="$(echo $2 | cut -d' ' -f2)"
c="$(echo $1 | cut -c1)"
case "$c" in
"+")
echo diff -u /dev/null "$filename($first_sha)";;
"-")
echo diff -u "$filename($first_sha)" /dev/null;;
"<")
echo diff -u "$filename($first_sha)" 
"$filename($second_sha)"
shift;;
*)
echo WHAT?
exit 1;;
esac
shift
done

which really shows what a horrid shell-person I am (I still use the old 
tools I learnt to use fifteen years ago. I bet you can do it trivially in 
perl or something sane, and I'm just stuck in the stone age of UNIX).

That makes it _very_ easy to parse. The example above is the diff between 
the initial commit and one of the more recent trees, so it has changes to 
everything, but a more normal thing would be

[EMAIL PROTECTED]:~/git> diff-tree 
787763499dc4f8cc345bc6ed8ee1e0ae31adedd6 
5b0c2695634b5bab2f5d63c7bb30f7e5815af470 | tr '\0' '\n'
<100664 01c92f2620a8e13e7cb7fd98ee644c6b65eeccb7 fsck-cache.c
>100664 81aa7bee003264ea302db835158e725eefa4012d fsck-cache.c

which tells you that the last commit changed just one file (it's from this 
one:

[EMAIL PROTECTED]:~/git> cat-file commit `cat .dircache/HEAD`
tree 5b0c2695634b5bab2f5d63c7bb30f7e5815af470
parent 81c53a1d3551f358860731481bb2d87179d221e6
author Linus Torvalds <[EMAIL PROTECTED]> Sat Apr  9 12:02:30 2005
committer Linus Torvalds <[EMAIL PROTECTED]> Sat Apr  9 12:02:30 2005
  

[2.6 patch] i386/x86_64 early_printk.c: make a variable static

[Adrian Bunk]

This patch makes a needlessly global variable static.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

--- linux-2.6.12-rc2-mm2-full/arch/x86_64/kernel/early_printk.c.old 
2005-04-09 20:51:23.0 +0200
+++ linux-2.6.12-rc2-mm2-full/arch/x86_64/kernel/early_printk.c 2005-04-09 
20:51:33.0 +0200
@@ -155,7 +155,7 @@
 };
 
 /* Direct interface for emergencies */
-struct console *early_console = _vga_console;
+static struct console *early_console = _vga_console;
 static int early_console_initialized = 0;
 
 void early_printk(const char *fmt, ...)

-
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/

[2.6 patch] crypto/api.c: make crypto_alg_lookup static

[Adrian Bunk]

This patch makes a needlessly global function static.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 crypto/api.c  |9 -
 crypto/internal.h |9 -
 2 files changed, 8 insertions(+), 10 deletions(-)

--- linux-2.6.12-rc2-mm2-full/crypto/internal.h.old 2005-04-09 
21:13:40.0 +0200
+++ linux-2.6.12-rc2-mm2-full/crypto/internal.h 2005-04-09 21:15:14.0 
+0200
@@ -47,15 +47,6 @@
return (void *)[1];
 }
 
-struct crypto_alg *crypto_alg_lookup(const char *name);
-
-/* A far more intelligent version of this is planned.  For now, just
- * try an exact match on the name of the algorithm. */
-static inline struct crypto_alg *crypto_alg_mod_lookup(const char *name)
-{
-   return try_then_request_module(crypto_alg_lookup(name), name);
-}
-
 #ifdef CONFIG_CRYPTO_HMAC
 int crypto_alloc_hmac_block(struct crypto_tfm *tfm);
 void crypto_free_hmac_block(struct crypto_tfm *tfm);
--- linux-2.6.12-rc2-mm2-full/crypto/api.c.old  2005-04-09 21:13:59.0 
+0200
+++ linux-2.6.12-rc2-mm2-full/crypto/api.c  2005-04-09 21:15:07.0 
+0200
@@ -33,7 +33,7 @@
module_put(alg->cra_module);
 }
 
-struct crypto_alg *crypto_alg_lookup(const char *name)
+static struct crypto_alg *crypto_alg_lookup(const char *name)
 {
struct crypto_alg *q, *alg = NULL;
 
@@ -54,6 +54,13 @@
return alg;
 }
 
+/* A far more intelligent version of this is planned.  For now, just
+ * try an exact match on the name of the algorithm. */
+static inline struct crypto_alg *crypto_alg_mod_lookup(const char *name)
+{
+   return try_then_request_module(crypto_alg_lookup(name), name);
+}
+
 static int crypto_init_flags(struct crypto_tfm *tfm, u32 flags)
 {
tfm->crt_flags = 0;

-
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: Kernel SCM saga..

[Ray Lee]

On Sat, 2005-04-09 at 19:40 +0200, Roman Zippel wrote:
> On Sat, 9 Apr 2005, Eric D. Mudama wrote:
> > > For example bk does something like this:
> > > 
> > > A1 -> A2 -> A3 -> BM
> > >   \-> B1 -> B2 --^
> > > 
> > > and instead of creating the merge changeset, one could merge them like
> > > this:
> > > 
> > > A1 -> A2 -> A3 -> B1 -> B2

> > I believe that flattening the change graph makes history reproduction
> > impossible, or alternately, you are imposing on each developer to test
> > the merge results at B1 + A1..3 before submission, but in doing so,
> > the test time may require additional test periods etc and with
> > sufficient velocity, might never close.
> 
> The merge result has to be tested either way, so I'm not exactly sure, 
> what you're trying to say.

The kernel changes. A lot. And often.

With that in mind, if (for example) A2 and A3 are simple changes that
are quick to test and B1 is large, or complex, or requires hours (days,
weeks) of testing to validate, then a maintainer's decision can
legitimately be to rebase a tree (say, -mm) upon the B1 line of
development, and toss the A2 branch back to those developers with a
"Sorry it didn't work out, something here causes Unhappiness with B1,
can you track down the problem and try again?"

Ray

-
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: Kernel SCM saga..

[Marcin Dalecki]

On 2005-04-09, at 17:42, Paul Jackson wrote:
Marcin wrote:
But what will impress you are either the price tag the
DB comes with or
the hardware it runs on :-)
The payroll for the staffing to care and feed for these
babies is often impressive as well.
Please don't forget the bill from the electric plant behind 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: [RFC,PATCH 3/4] Change synchronize_kernel to _rcu and _sched

[Manfred Spraul]

On Sat, 9 Apr 2005, Francois Romieu wrote:

> Manfred Spraul <[EMAIL PROTECTED]> :
> > [Jeff added to cc list - it's a network driver question]
> [...]
> > I haven't read the whole driver, but what about
> > spin_unlock_wait(>xmit_lock);
> > ?
>
> The race here is a dev->close() against dev->hard_start_xmit() one where
> dev->hard_start_xmit() does not do any locking at all.
>
I always thought that all callers of dev->hard_start_xmit() acquire
dev->xmit_lock before calling hard_start_xmit().

Is that assumption wrong? I think I even rely on that in one of my
drivers.

--
Manfred

-
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/

memory_barrier

[Bart De Schuymer]

Hi,

Is there any reason why __memory_barrier() is still referenced in the
kernel source?

grep -r memory_barrier gave the following back, which at first seems to
suggest barrier() is defined using some phantom __memory_barrier(),
quite deceiving...


include/linux/compiler-intel.h:#define barrier() __memory_barrier()
include/linux/compiler.h:# define barrier() __memory_barrier()
include/asm-m32r/system.h: * memory_barrier() for examples and URLs to more 
information.
include/asm-m32r/system.h: *  memory_barrier();
include/asm-m32r/system.h: *  memory_barrier();
include/asm-i386/system.h: * memory_barrier() for examples and URLs to more 
information.
include/asm-i386/system.h: *memory_barrier();
include/asm-i386/system.h: *memory_barrier();
include/asm-mips/system.h: * memory_barrier() for examples and URLs to more 
information.
include/asm-mips/system.h: *memory_barrier();
include/asm-mips/system.h: *memory_barrier();
include/asm-ia64/intel_intrin.h:void __memory_barrier(void);
include/asm-ia64/intel_intrin.h:#define ia64_barrier()  
__memory_barrier()


cheers,
Bart


-
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 0/5] autoparam

[Domen Puncer]

On 21/03/05 00:06 +0100, Magnus Damm wrote:
> Here are a set of patches that makes it possible to autogenerate kernel 
> command
> line documentation from the source code. The approach is rather 
> straightforward
> - the parameter name, the type and the description are stored in a section 
> called __param_strings. After vmlinux is built this section is extracted using
> objcopy and a script is used to generate a primitive - but up to date - 
> document.

I think it's a great idea. A needed feature with simple implementation.
I like it.

> 
> Right now the section is left in the kernel binary. The document is currently
> not generated from the Makefile, so the curious user should perform:

Any plans to make this a complete patch?

> 
> $ objcopy -j __param_strings vmlinux -O binary foo
> $ chmod a+x scripts/section2text.rb
> $ cat foo | ./scripts/section2text.rb
> 
> And yeah, you need to install ruby to run the script.

Attached a perl script, that has almost the same output. (I think
perl is more usual on linux machines)

> 
> The ruby script section2text.rb does some checks to see if MODULE_PARM_DESC()
> is used without module_param(). You will find interesting typos.
> 
> Future work that extends this idea could include replacing __setup(name) with 
> __setup(name, descr). And storing the documentation somewhere to make it easy
> for the end user to look up the generated parameter list from the boot loader.

And kernel-parameters.txt will never again have obsoleted options :-)


Domen


section2text.pl
Description: Perl program

[PATCH] Re: Kernel SCM saga..

[Petr Baudis]

Dear diary, on Sat, Apr 09, 2005 at 09:08:59AM CEST, I got a letter
where "Randy.Dunlap" <[EMAIL PROTECTED]> told me that...
> On Sat, 9 Apr 2005 04:53:57 +0200 Petr Baudis wrote:
..snip..
> |   FWIW, I made few small fixes (to prevent some trivial usage errors to
> | cause cache corruption) and added scripts gitcommit.sh, gitadd.sh and
> | gitlog.sh - heavily inspired by what already went through the mailing
> | list. Everything is available at http://pasky.or.cz/~pasky/dev/git/
> | (including .dircache, even though it isn't shown in the index), the
> | cumulative patch can be found below. The scripts aim to provide some
> | (obviously very interim) more high-level interface for git.
> | 
> |   I'm now working on tree-diff.c which will (surprise!) produce a diff
> | of two trees (I'll finish it after I get some sleep, though), and then I
> | will probably do some dwimmy gitdiff.sh wrapper for tree-diff and
> | show-diff. At that point I might get my hand on some pull more kind to
> | local changes.
> 
> Hi,

  Hi,

> I'll look at your scripts this weekend.  I've also been
> working on some, but mine are a bit more experimental (cruder)
> than yours are.  Anyway, here they are (attached) -- also
> available at http://developer.osdl.org/rddunlap/git/
> 
> gitin : checkin/commit
> gitwhat sha1 : what is that sha1 file (type and contents if blob or commit)
> gitlist (blob, commit, tree, or all) :
>   list all objects with type (commit, tree, blob, or all)

  thanks - I had a look, but so far I borrowed only the prompt message
from your gitin. ;-) I'm not sure if gitwhat would be useful for me in
any way and gitlist doesn't appear too practical to me either.

  In the meantime, I've made some progress too. I made ls-tree, which
will just convert the tree object to a human readable (and script
processable) form, and wrapper gitls.sh, which will also try to guess
the tree ID. parent-id will just return the commit ID(s) of the previous
commit(s), practical if you want to diff against the previous commit
easily etc.  And finally, there is gitdiff.sh, which will produce a diff
of any two trees.

  Everything is again available at http://pasky.or.cz/~pasky/dev/git/
and again including .dircache, even though it's invisible in the index.
The cumulative patch (against 0.03) is there as well as below, generated
by the

./gitdiff.sh 0af20307bb4c634722af0f9203dac7b3222c4a4f

command. The empty entries are changed modes (664 vs 644), I will yet
have to think about how to denote them if the content didn't change;
or I might ignore them altogether...?

  You can obviously fetch any arbitrary change by doing the appropriate
gitdiff.sh call. You can find the ids in the ChangeLog, which was
generated by the plain

./gitlog.sh

command. (That is for HEAD. 0af20307bb4c634722af0f9203dac7b3222c4a4f is
the last commit on the Linus' branch, pass that to gitlog.sh to get his
ChangeLog. ;-)

  Next, I will probably do some bk-style pull tool. Or perhaps first
a gitpatch.sh which will verify the sha1s and do the mode changes.

  Linus, could you please have a look and tell me what do you think
about it so far?

  Thanks,

Petr Baudis

Index: Makefile
===
--- 6be98a9e92a3f131a3fdf0dc3a8576fba6421569/Makefile (mode:100664 
sha1:270cd4f8a8bf10cd513b489c4aaf76c14d4504a7)
+++ 3f6cc0ad3e076e05281438b0de69a7d6a5522d17/Makefile (mode:100644 
sha1:185ff422e68984e68da011509dec116f05fc6f8d)
@@ -1,7 +1,7 @@
 CFLAGS=-g -O3 -Wall
 CC=gcc
 
-PROG=update-cache show-diff init-db write-tree read-tree commit-tree cat-file 
fsck-cache
+PROG=update-cache show-diff init-db write-tree read-tree commit-tree cat-file 
fsck-cache ls-tree
 
 all: $(PROG)
 
@@ -30,6 +30,9 @@
 cat-file: cat-file.o read-cache.o
$(CC) $(CFLAGS) -o cat-file cat-file.o read-cache.o $(LIBS)
 
+ls-tree: ls-tree.o read-cache.o
+   $(CC) $(CFLAGS) -o ls-tree ls-tree.o read-cache.o $(LIBS)
+
 fsck-cache: fsck-cache.o read-cache.o
$(CC) $(CFLAGS) -o fsck-cache fsck-cache.o read-cache.o $(LIBS)
 
Index: README
===
Index: cache.h
===
Index: cat-file.c
===
Index: commit-tree.c
===
Index: fsck-cache.c
===
Index: gitadd.sh
===
--- 6be98a9e92a3f131a3fdf0dc3a8576fba6421569/gitadd.sh
+++ 3f6cc0ad3e076e05281438b0de69a7d6a5522d17/gitadd.sh (mode:100755 
sha1:d23be758c0c9fc1cf9756bcd3ee4d7266c60a2c9)
@@ -0,0 +1,13 @@
+#!/bin/sh
+#
+# Add new file to a GIT repository.
+# Copyright (c) Petr Baudis, 2005
+#
+# Takes a list of file names at the command line, and schedules them
+# for addition to 

[2.6 patch] let SOUND_AD1889 depend on PCI

[Adrian Bunk]

Compiling SOUND_AD1889 with PCI=n results in the following compile 
error:

<--  snip  -->

...
  LD  .tmp_vmlinux1
sound/built-in.o(.text+0x24f0c): In function `ad1889_remove':
: undefined reference to `pci_release_region'
make: *** [.tmp_vmlinux1] Error 1

<--  snip  -->


This patch adds the missing dependency on PCI.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was already sent on:
- 1 Apr 2005

--- linux-2.6.12-rc1-mm4-full/sound/oss/Kconfig.old 2005-04-01 
00:23:11.0 +0200
+++ linux-2.6.12-rc1-mm4-full/sound/oss/Kconfig 2005-04-01 00:23:39.0 
+0200
@@ -556,7 +556,7 @@
 
 config SOUND_AD1889
tristate "AD1889 based cards (AD1819 codec) (EXPERIMENTAL)"
-   depends on EXPERIMENTAL && SOUND_OSS
+   depends on EXPERIMENTAL && SOUND_OSS && PCI
help
  Say M here if you have a sound card based on the Analog Devices
  AD1889 chip.

-
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/

[2.6 patch] drivers/input/joystick/spaceorb.c: fix an array overflow

[Adrian Bunk]

This patch fixes an array overflow found by the Coverity checker.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was already sent on:
- 27 Mar 2005

--- linux-2.6.12-rc1-mm1-full/drivers/input/joystick/spaceorb.c.old 
2005-03-23 02:12:33.0 +0100
+++ linux-2.6.12-rc1-mm1-full/drivers/input/joystick/spaceorb.c 2005-03-23 
02:16:18.0 +0100
@@ -116,7 +116,7 @@ static void spaceorb_process_packet(stru
 
case 'K':   /* Button data */
if (spaceorb->idx != 5) return;
-   for (i = 0; i < 7; i++)
+   for (i = 0; i < 6; i++)
input_report_key(dev, spaceorb_buttons[i], 
(data[2] >> i) & 1);
 
break;

-
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/

[2.6 patch] sound/oss/sonicvibes.c: fix an array overflow

[Adrian Bunk]

This patch fixes an array overflow found by the Coverity checker.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was already sent on:
- 27 Mar 2005

--- linux-2.6.12-rc1-mm1-full/sound/oss/sonicvibes.c.old2005-03-23 
01:53:13.0 +0100
+++ linux-2.6.12-rc1-mm1-full/sound/oss/sonicvibes.c2005-03-23 
01:55:11.0 +0100
@@ -1146,13 +1146,13 @@ static int mixer_ioctl(struct sv_state *
for (i = 0; i < SOUND_MIXER_NRDEVICES; i++) {
if (!(val & (1 << i)))
continue;
if (mixtable[i].rec)
break;
}
-   if (!mixtable[i].rec)
+   if (i == SOUND_MIXER_NRDEVICES)
return 0;
spin_lock_irqsave(>lock, flags);
frobindir(s, SV_CIMIX_ADCINL, 0x1f, mixtable[i].rec << 5);
frobindir(s, SV_CIMIX_ADCINR, 0x1f, mixtable[i].rec << 5);
spin_unlock_irqrestore(>lock, flags);
return 0;

-
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/

[2.6 patch] drivers/serial/jsm/: make 2 functions static

[Adrian Bunk]

- Forwarded message from Adrian Bunk <[EMAIL PROTECTED]> -

Date:   Sat, 2 Apr 2005 01:38:51 +0200
From: Adrian Bunk <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org
Subject: [2.6 patch drivers/serial/jsm/: make 2 functions static

This patch makes two needlessly global functions static.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was already sent on:
- 2 Apr 2005

 drivers/serial/jsm/jsm.h |1 -
 drivers/serial/jsm/jsm_neo.c |2 +-
 drivers/serial/jsm/jsm_tty.c |4 +++-
 3 files changed, 4 insertions(+), 3 deletions(-)

--- linux-2.6.12-rc1-mm4-full/drivers/serial/jsm/jsm_neo.c.old  2005-04-02 
00:20:17.0 +0200
+++ linux-2.6.12-rc1-mm4-full/drivers/serial/jsm/jsm_neo.c  2005-04-02 
00:20:34.0 +0200
@@ -688,7 +688,7 @@
 /*
  * No locks are assumed to be held when calling this function.
  */
-void neo_clear_break(struct jsm_channel *ch, int force)
+static void neo_clear_break(struct jsm_channel *ch, int force)
 {
u64 lock_flags;
 
--- linux-2.6.12-rc1-mm4-full/drivers/serial/jsm/jsm.h.old  2005-04-02 
00:20:44.0 +0200
+++ linux-2.6.12-rc1-mm4-full/drivers/serial/jsm/jsm.h  2005-04-02 
00:20:54.0 +0200
@@ -393,7 +393,6 @@
 int jsm_uart_port_init(struct jsm_board *);
 int jsm_remove_uart_port(struct jsm_board *);
 void jsm_input(struct jsm_channel *ch);
-void jsm_carrier(struct jsm_channel *ch);
 void jsm_check_queue_flow_control(struct jsm_channel *ch);
 
 #endif
--- linux-2.6.12-rc1-mm4-full/drivers/serial/jsm/jsm_tty.c.old  2005-04-02 
00:21:02.0 +0200
+++ linux-2.6.12-rc1-mm4-full/drivers/serial/jsm/jsm_tty.c  2005-04-02 
00:21:18.0 +0200
@@ -31,6 +31,8 @@
 
 #include "jsm.h"
 
+static void jsm_carrier(struct jsm_channel *ch);
+
 static inline int jsm_get_mstat(struct jsm_channel *ch)
 {
unsigned char mstat;
@@ -760,7 +762,7 @@
jsm_printk(IOCTL, INFO, >ch_bd->pci_dev, "finish\n");
 }
 
-void jsm_carrier(struct jsm_channel *ch)
+static void jsm_carrier(struct jsm_channel *ch)
 {
struct jsm_board *bd;
 

-
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/

[2.6 patch] drivers/pnp/pnpacpi/rsparser.c: fix an array overflow

[Adrian Bunk]

This patch fixes an array overflow found by the Coverity checker.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was already sent on:
- 27 Mar 2005

--- linux-2.6.12-rc1-mm1-full/drivers/pnp/pnpacpi/rsparser.c.old
2005-03-23 02:58:31.0 +0100
+++ linux-2.6.12-rc1-mm1-full/drivers/pnp/pnpacpi/rsparser.c2005-03-23 
03:02:49.0 +0100
@@ -94,8 +94,8 @@
 pnpacpi_parse_allocated_dmaresource(struct pnp_resource_table * res, int dma)
 {
int i = 0;
-   while (!(res->dma_resource[i].flags & IORESOURCE_UNSET) &&
-   i < PNP_MAX_DMA)
+   while (i < PNP_MAX_DMA &&
+   !(res->dma_resource[i].flags & IORESOURCE_UNSET))
i++;
if (i < PNP_MAX_DMA) {
res->dma_resource[i].flags = IORESOURCE_DMA;  // Also clears 
_UNSET flag

-
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/

[2.6 patch] drivers/video/radeonfb.c: fix an array overflow

[Adrian Bunk]

This patch fixes an array overflow found by the Coverity checker.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was already sent on:
- 27 Mar 2005

--- linux-2.6.12-rc1-mm1-full/drivers/video/radeonfb.c.old  2005-03-23 
01:50:14.0 +0100
+++ linux-2.6.12-rc1-mm1-full/drivers/video/radeonfb.c  2005-03-23 
01:50:30.0 +0100
@@ -2107,7 +2107,7 @@ static void radeon_write_mode (struct ra
 
 
if (rinfo->arch == RADEON_M6) {
-   for (i=0; i<8; i++)
+   for (i=0; i<7; i++)
OUTREG(common_regs_m6[i].reg, common_regs_m6[i].val);
} else {
for (i=0; i<9; i++)

-
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/

[-mm patch] net/ieee80211/ieee80211_tx.c: swapped memset arguments

[Adrian Bunk]

Fix swapped memset() arguments in  net/ieee80211/ieee80211_tx.c  
found by Maciej Soltysiak.

Patch by Jesper Juhl.

Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was sent by Jesper Juhl on:
- 3 Apr 2005

--- linux-2.6.12-rc1-mm4-orig/net/ieee80211/ieee80211_tx.c  2005-03-31 
21:20:08.0 +0200
+++ linux-2.6.12-rc1-mm4/net/ieee80211/ieee80211_tx.c   2005-04-03 
00:34:22.0 +0200
@@ -223,7 +223,7 @@ struct ieee80211_txb *ieee80211_alloc_tx
if (!txb)
return NULL;
 
-   memset(txb, sizeof(struct ieee80211_txb), 0);
+   memset(txb, 0, sizeof(struct ieee80211_txb));
txb->nr_frags = nr_frags;
txb->frag_size = txb_size;
 


-
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/

[2.6 patch] drivers/pnp/pnpbios/rsparser.c: fix an array overflow

[Adrian Bunk]

This patch fixes an array overflow found by the Coverity checker.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was already sent on:
- 27 Mar 2005

--- linux-2.6.12-rc1-mm1-full/drivers/pnp/pnpbios/rsparser.c.old
2005-03-23 03:04:17.0 +0100
+++ linux-2.6.12-rc1-mm1-full/drivers/pnp/pnpbios/rsparser.c2005-03-23 
03:05:21.0 +0100
@@ -72,7 +72,9 @@
 pnpbios_parse_allocated_dmaresource(struct pnp_resource_table * res, int dma)
 {
int i = 0;
-   while (!(res->dma_resource[i].flags & IORESOURCE_UNSET) && i < 
PNP_MAX_DMA) i++;
+   while (i < PNP_MAX_DMA && 
+   !(res->dma_resource[i].flags & IORESOURCE_UNSET))
+   i++;
if (i < PNP_MAX_DMA) {
res->dma_resource[i].flags = IORESOURCE_DMA;  // Also clears 
_UNSET flag
if (dma == -1) {

-
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/

reboot problem in 2.6.x kernels, where 2.4.x kernels work well

[Valery Khamenya]

Hi all,

as I reported before (see here: 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0503.3/0975.html or
here: http://lkml.org/lkml/2005/3/28/38 ) -- there is a reboot problem
under 2.6.x
kernels with VIA EPIA MS boards.

Now I have found that kernels 2.4.x seem to work well under different 
reboot combinations (apm=on|off acpi=on|off reboot=b|w) i tried so far.

So, it looks like problem is rather specific to kernels 2.6.x only.
No idea why though.

P.S. Thank you for Cc answers to me.
-- 
Valery A.Khamenya
-
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: Kernel SCM saga..

[Roman Zippel]

Hi,

On Sat, 9 Apr 2005, Eric D. Mudama wrote:

> > For example bk does something like this:
> > 
> > A1 -> A2 -> A3 -> BM
> >   \-> B1 -> B2 --^
> > 
> > and instead of creating the merge changeset, one could merge them like
> > this:
> > 
> > A1 -> A2 -> A3 -> B1 -> B2
> > 
> > This results in a simpler repository, which is more scalable and which
> > is easier for users to work with (e.g. binary bug search).
> > The disadvantage would be it will cause more minor conflicts, when changes
> > are pulled back into the original tree, but which should be easily
> > resolvable most of the time.
> 
> The kicker comes that B1 was developed based on A1, so any test
> results were based on B1 being a single changeset delta away from A1. 
> If the resulting 'BM' fails testing, and you've converted into the
> linear model above where B2 has failed, you lose the ability to
> isolate B1's changes and where they came from, to revalidate the
> developer's results.

What good does it do if you can revalidate the original B1? The important 
point is that the end result works and if it only fails in the merged 
version you have a big problem. The serialized version gives you the 
chance to test whether it fails in B1 or B2.

> I believe that flattening the change graph makes history reproduction
> impossible, or alternately, you are imposing on each developer to test
> the merge results at B1 + A1..3 before submission, but in doing so,
> the test time may require additional test periods etc and with
> sufficient velocity, might never close.

The merge result has to be tested either way, so I'm not exactly sure, 
what you're trying to say.

bye, Roman
-
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: Kernel SCM saga..

[Paul Jackson]

>  (b) while I depend on the fact that if the SHA of an object matches, the 
>  objects are the same, I generally try to avoid the reverse 
>  dependency.

It might be a valid point that you want to leave the door open to using
a different (than SHA1) digest.  (So this means you going to store it
as an ASCII string, right?)

But I don't see how that applies here.  Any optimization that avoids
rereading old versions if the digests match will never trigger on the
day you change digests.  No problem here - you doomed to reread the old
version in any case.

Either you got your logic backwards, or I need another cup of coffee.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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/

[2.6 patch] remove BK documentation

[Adrian Bunk]

Whatever the new SCM will be, there's no longer a reason to document the 
obsolete BK usage.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 Documentation/00-INDEX |2 
 Documentation/BK-usage/00-INDEX|   51 ---
 Documentation/BK-usage/bk-kernel-howto.txt |  283 -
 Documentation/BK-usage/bk-make-sum |   34 --
 Documentation/BK-usage/bksend  |   36 --
 Documentation/BK-usage/bz64wrap|   41 ---
 Documentation/BK-usage/cpcset  |   36 --
 Documentation/BK-usage/cset-to-linus   |   49 ---
 Documentation/BK-usage/csets-to-patches|   44 ---
 Documentation/BK-usage/gcapatch|8 
 Documentation/BK-usage/unbz64wrap  |   25 -
 fs/cifs/README |6 
 12 files changed, 3 insertions(+), 612 deletions(-)

--- linux-2.6.12-rc2-mm2-full/Documentation/00-INDEX.old2005-04-09 
19:06:53.0 +0200
+++ linux-2.6.12-rc2-mm2-full/Documentation/00-INDEX2005-04-09 
19:06:59.0 +0200
@@ -12,8 +12,6 @@
 
 00-INDEX
- this file.
-BK-usage/
-   - directory with info on BitKeeper.
 BUG-HUNTING
- brute force method of doing binary search of patches to find bug.
 Changes
--- linux-2.6.12-rc2-mm2-full/fs/cifs/README.old2005-04-09 
19:08:06.0 +0200
+++ linux-2.6.12-rc2-mm2-full/fs/cifs/README2005-04-09 19:08:29.0 
+0200
@@ -32,9 +32,9 @@
 6) make modules (or "make" if CIFS VFS not to be built as a module)
 
 For Linux 2.6:
-1) Download the kernel (e.g. from http://www.kernel.org or from bitkeeper
-at bk://linux.bkbits.net/linux-2.5) and change directory into the top
-of the kernel directory tree (e.g. /usr/src/linux-2.5.73)
+1) Download the kernel (e.g. from http://www.kernel.org
+and change directory into the top of the kernel directory tree
+(e.g. /usr/src/linux-2.5.73)
 2) make menuconfig (or make xconfig)
 3) select cifs from within the network filesystem choices
 4) save and exit
--- linux-2.6.12-rc2-mm2-full/Documentation/BK-usage/00-INDEX   2005-03-02 
08:37:49.0 +0100
+++ /dev/null   2005-03-19 22:42:59.0 +0100
@@ -1,51 +0,0 @@
-bk-kernel-howto.txt: Description of kernel workflow under BitKeeper
-
-bk-make-sum: Create summary of changesets in one repository and not
-another, typically in preparation to be sent to an upstream maintainer.
-Typical usage:
-   cd my-updated-repo
-   bk-make-sum ~/repo/original-repo
-   mv /tmp/linus.txt ../original-repo.txt
-
-bksend: Create readable text output containing summary of changes, GNU
-patch of the changes, and BK metadata of changes (as needed for proper
-importing into BitKeeper by an upstream maintainer).  This output is
-suitable for emailing BitKeeper changes.  The recipient of this output
-may pipe it directly to 'bk receive'.
-
-bz64wrap: helper script. Uncompressed input is piped to this script,
-which compresses its input, and then outputs the uu-/base64-encoded
-version of the compressed input.
-
-cpcset: Copy changeset between unrelated repositories.
-Attempts to preserve changeset user, user address, description, in
-addition to the changeset (the patch) itself.
-Typical usage:
-   cd my-updated-repo
-   bk changes  # looking for a changeset...
-   cpcset 1.1511 . ../another-repo
-
-csets-to-patches: Produces a delta of two BK repositories, in the form
-of individual files, each containing a single cset as a GNU patch.
-Output is several files, each with the filename "/tmp/rev-$REV.patch"
-Typical usage:
-   cd my-updated-repo
-   bk changes -L ~/repo/original-repo 2>&1 | \
-   perl csets-to-patches
-
-cset-to-linus: Produces a delta of two BK repositories, in the form of
-changeset descriptions, with 'diffstat' output created for each
-individual changset.
-Typical usage:
-   cd my-updated-repo
-   bk changes -L ~/repo/original-repo 2>&1 | \
-   perl cset-to-linus > summary.txt
-
-gcapatch:  Generates patch containing changes in local repository.
-Typical usage:
-   cd my-updated-repo
-   gcapatch > foo.patch
-
-unbz64wrap: Reverse an encoded, compressed data stream created by
-bz64wrap into an uncompressed, typically text/plain output.
-
--- linux-2.6.12-rc2-mm2-full/Documentation/BK-usage/bk-kernel-howto.txt
2005-03-02 08:38:10.0 +0100
+++ /dev/null   2005-03-19 22:42:59.0 +0100
@@ -1,283 +0,0 @@
-
-  Doing the BK Thing, Penguin-Style
-
-
-
-
-This set of notes is intended mainly for kernel developers, occasional
-or full-time, but sysadmins and power users may find parts of it useful
-as well.  It assumes at least a basic familiarity with CVS, both at a
-user level (use on the cmd line) and at a higher level (client-server model).
-Due to the author's background, an operation may be described in terms
-of CVS, or in terms of how that operation differs from CVS.
-
-This is -not- intended to be BitKeeper 

Re: Kernel SCM saga..

[Paul Jackson]

Linus wrote:
> In "git", you usually care about 
> the old contents too.

True - in your case, you probably want the old contents
so might as well dig them out as soon as it becomes
convenient to have them.

I was objecting to your claim that you _had_ to dig out
the old contents to determine if a file changed.

You don't _have_ to ... but I agree that it's a good
time to do so.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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: Kernel SCM saga..

[Roman Zippel]

Hi,

On Fri, 8 Apr 2005, Linus Torvalds wrote:

> Yes.  Per-file history is expensive in git, because if the way it is 
> indexed. Things are indexed by tree and by changeset, and there are no 
> per-file indexes.
> 
> You could create per-file _caches_ (*) on top of git if you wanted to make
> it behave more like a real SCM, but yes, it's all definitely optimized for
> the things that _I_ tend to care about, which is the whole-repository
> operations.

Per file history is also expensive for another reason. The basic reason is 
that I think that a hash based storage is not the best approach for SCM. 
It's lacking locality, so the more it grows the more it has to seek to 
collect all the data.
To reduce the space usage you could replace the parent file with a sha1 
reference + delta to the new file. This is basically what monotone does 
and might cause perfomance problems if you need to restore old versions 
(e.g. if you want to annotate a file).

bye, Roman
-
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: Kernel SCM saga..

[Paul Jackson]

Linus wrote:
> (you need to remember to escape '%' 
> too when you do that ;).

No - don't have to.  Not if I don't mind giving fools that embed
newlines in paths second class service.

In my case, if I create a file named "foo\nbar", then backup and restore
it, I end up with a restored file named "foo%0Abar".  If I had backed up
another file named "foo%0Abar", and now restore it, it collides, and
last one to be restored wins.  If I really need the "foo\nbar" file back
as originally named, I will have to dig it out by hand.

I dare say that Linux kernel source does not require first class support
for newlines embedded in pathnames.

> ASCII isn't magical.

No - but it's damn convenient.  Alot of tools work on line-oriented
ASCII that don't work elsewhere.

I guess Perl-hackers won't care much, but those working with either
classic shell script tools or Python will find line formatted ASCII more
convenient.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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: Kernel SCM saga..

[Eric D. Mudama]

On Apr 8, 2005 4:52 PM, Roman Zippel <[EMAIL PROTECTED]> wrote:
> The problem is you pay a price for this. There must be a reason developers
> were adding another GB of memory just to run BK.
> Preserving the complete merge history does indeed make repeated merges
> simpler, but it builds up complex meta data, which has to be managed
> forever. I doubt that this is really an advantage in the long term. I
> expect that we were better off serializing changesets in the main
> repository. For example bk does something like this:
> 
> A1 -> A2 -> A3 -> BM
>   \-> B1 -> B2 --^
> 
> and instead of creating the merge changeset, one could merge them like
> this:
> 
> A1 -> A2 -> A3 -> B1 -> B2
> 
> This results in a simpler repository, which is more scalable and which
> is easier for users to work with (e.g. binary bug search).
> The disadvantage would be it will cause more minor conflicts, when changes
> are pulled back into the original tree, but which should be easily
> resolvable most of the time.

The kicker comes that B1 was developed based on A1, so any test
results were based on B1 being a single changeset delta away from A1. 
If the resulting 'BM' fails testing, and you've converted into the
linear model above where B2 has failed, you lose the ability to
isolate B1's changes and where they came from, to revalidate the
developer's results.

With bugs and fixes that can be validated in a few hours, this may not
be a problem, but when chasing a bug that takes days or weeks to
manifest, that a developer swears they fixed, one has to be able to
reproduce their exact test environment.

I believe that flattening the change graph makes history reproduction
impossible, or alternately, you are imposing on each developer to test
the merge results at B1 + A1..3 before submission, but in doing so,
the test time may require additional test periods etc and with
sufficient velocity, might never close.  This is the problem CVS has
if you don't create micro branches for every single modification.

--eric
-
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/

2.6.12-rc2: Promise SATA150 TX4 failures

[Joerg Sommrey]

Hi all,

just tried 2.6.12-rc2 and I still have the same errors from my SATA
disks as with 2.6.11.  The setup is a bit complex.  The relevant parts (I
think) are:

Adaptec AHA-2940UW SCSI-controller, attached are:
1 harddisk /dev/sda
1 DDS3 streamer /dev/st0

Promise SATA150 TX4 controller, attached are:
2 identical hardisks /dev/sdb and /dev/sdc

/dev/sda consists of the root partition, a swap partition and 4 other
partitions that are physical volumes for dm volume group /dev/vg1

/dev/sdb and /dev/sdc have two partitions each, the first of both make
a RAID-0 array /dev/md0 and the second of both make a md RAID-1 array
/dev/md1

/dev/md0 and /dev/md1 are the physical volumes for dm volume groups
/dev/vg2 and /dev/vg3 resp.

To trigger the failure:
- For all logical volumes in /dev/vg1, /dev/vg2 and /dev/vg3 a snapshot is
  created.
- All snapshots are mounted read-only in a "snapshot hierarchy" under
  /snap.
- A backup to tape is taken using something like:
  find /snap -print | cpio -oaH crc -F /dev/st0
  Backup must go to tape, no problem with /dev/null
- At this point, some additional i/o on the SATA disks cause the whole
  box to hang. Mostly some errors are written to syslog, they are
  always similar:
Apr  9 01:30:35 bear kernel: ata2: status=0x51 { DriveReady SeekComplete Error 
}Apr  9 01:30:35 bear kernel: ata2: called with no error (51)!
Apr  9 01:30:35 bear kernel: SCSI error : <2 0 0 0> return code = 0x802
Apr  9 01:30:35 bear kernel: sdc: Current: sense key: Medium Error
Apr  9 01:30:35 bear kernel: Additional sense: Unrecovered read error - 
auto reallocate failed
Apr  9 01:30:35 bear kernel: end_request: I/O error, dev sdc, sector 43100350
Apr  9 01:30:35 bear kernel: raid1: Disk failure on sdc2, disabling device.
Apr  9 01:30:35 bear kernel: ^IOperation continuing on 1 devices

The errors are always reported for /dev/sdc2, the second device of a
RAID-1 array.  After reboot I am able to raidhotadd the failed partition
without problems.

The problem is 100% reproducible.

The hang is not a "hard hang": X keeps running, the watchdog doesn't hit
but no new processes can be started.  Syslog entries stop after some time
(from a few seconds to several minutes).

The problem appeared somewhere between 2.6.10 and 2.6.11.
2.6.10: ok
2.6.10-ac8: ok
2.6.10-ac11:failed
2.6.11: failed
2.6.12-rc2: failed

I'd be glad if there would be a solution for this problem as it prevents
me from using any newer kernel.

-jo

-- 
-rw-r--r--  1 jo users 63 2005-04-09 09:31 /home/jo/.signature
-
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/

PROPOSAL !

[Lee Chen]

Dear Friend,
I am Mr LEE CHEN,managinig director of China National Arts & Crafts
Import./Export. Corp. we are a group of business men who deal on Art and
Craft and export into the Canada/America and Europe. We are searching for
representatives who can help us establish a medium of getting to our
customers in the Canada/America and Europe as well as making payments
through you to us.Please if you are interested in transacting business with
us we will be very glad.
Please contact us for more information.
Subject to your satisfaction you will be given the opportunity to negotiate
your mode of which we will pay for your services as our representative in
Canada/America and Europe Please if you are interested.
We look foward in hearing from you.
Thanks In advance
Managing Director,
Mr.LEE CHEN
  

Re: Kernel SCM saga..

[Roman Zippel]

Hi,

On Fri, 8 Apr 2005, Linus Torvalds wrote:

> Also, I suspect that BKCVS actually bothers to get more details out of a
> BK tree than I cared about. People have pestered Larry about it, so BKCVS
> exports a lot of the nitty-gritty (per-file comments etc) that just
> doesn't actually _matter_, but people whine about. Me, I don't care. My
> sparse-conversion just took the important parts.

As soon as you want to synchronize and merge two trees, you will know why 
this information does matter.
(/me looks closer at the sparse-conversion...)
It seems you exported the complete parent information and this is exactly 
the "nitty-gritty" I was "whining" about and which is not available via 
bkcvs or bkweb and it's the most crucial information to make the bk data 
useful outside of bk. Larry was previously very clear about this that he 
considers this proprietary bk meta data and anyone attempting to export 
this information is in violation with the free bk licence, so you indeed 
just took the important parts and this is/was explicitly verboten for 
normal bk users.

bye, Roman
-
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] radeonfb: (#2) Implement proper workarounds for PLL accesses

[Andreas Schwab]

Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:

> Can you redo the counting of the workarounds with the patch ?

Switching from X to console:

radeon_write_pll_regs: INPLL
radeon_write_pll_regs: INPLL
radeon_write_mode: OUTPLL
radeonfb_engine_reset: INPLL
radeonfb_engine_reset: OUTPLL
radeonfb_engine_reset: OUTPLL
radeonfb_setcmap: INPLL
radeonfb_setcmap: OUTPLL
radeonfb_setcmap: OUTPLL
radeon_write_pll_regs: INPLL
radeon_write_pll_regs: INPLL
radeon_write_mode: OUTPLL
radeonfb_engine_reset: INPLL
radeonfb_engine_reset: OUTPLL
radeonfb_engine_reset: OUTPLL
radeonfb_setcmap: INPLL
radeonfb_setcmap: OUTPLL
radeonfb_setcmap: OUTPLL
radeonfb_setcmap: INPLL
radeonfb_setcmap: OUTPLL
radeonfb_setcmap: OUTPLL
radeonfb_setcmap: INPLL
radeonfb_setcmap: OUTPLL
radeonfb_setcmap: OUTPLL
radeonfb_setcmap: INPLL
radeonfb_setcmap: OUTPLL

Switching from console to X:

radeonfb_setcmap: OUTPLL
radeon_write_pll_regs: INPLL
radeon_write_pll_regs: INPLL
radeon_write_mode: OUTPLL
radeonfb_engine_reset: INPLL
radeonfb_engine_reset: OUTPLL
radeonfb_engine_reset: OUTPLL
radeonfb_setcmap: INPLL
radeonfb_setcmap: OUTPLL
radeonfb_setcmap: OUTPLL
agpgart: Putting AGP V2 device at :00:0b.0 into 1x mode
agpgart: Putting AGP V2 device at :00:10.0 into 1x mode
radeonfb_setcolreg: INPLL
radeonfb_setcolreg: OUTPLL
radeonfb_setcolreg: OUTPLL
... last three lines repeated 63 times

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
-
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: Kernel SCM saga..

[Linus Torvalds]

On Sat, 9 Apr 2005, Paul Jackson wrote:
>
> > in order to avoid having to worry about special characters
> > they are NUL-terminated)
> 
> Would this be a possible alternative - newline terminated (convert any
> newlines embedded in filenames to the 3 chars '%0A', and leave it as an
> exercise to the reader to de-convert them.)

Sure, you could obviously do escaping (you need to remember to escape '%' 
too when you do that ;).

However, whenever you do escaping, that means that you're already going to 
have to use a tool to unpack the dang thing. So you didn't actually win 
anything. I pretty much guarantee that my existing format is easier to 
unpack than your escaped format.

ASCII isn't magical.

This is "fsck_tree()", which walks the unpacked tree representation and 
checks that it looks sane and marks the sha1's it finds as being 
needed (so that you can do reachability analysis in a second pass). It's 
not exactly complicated:

static int fsck_tree(unsigned char *sha1, void *data, unsigned long 
size)
{
while (size) {
int len = 1+strlen(data);
unsigned char *file_sha1 = data + len;
char *path = strchr(data, ' ');
if (size < len + 20 || !path)
return -1;
data += len + 20;
size -= len + 20;
mark_needs_sha1(sha1, "blob", file_sha1);
}
return 0;
}

and there's one HUGE advantage to _not_ having escaping: sorting and
comparing.

If you escape things, you now have to decide how you sort filenames. Do
you sort them by the escaped representation, or by the "raw"  
representation? Do you always have to escape or unescape the name in order 
to sort it.

So I like ASCII as much as the next guy, but it's not a religion. If there 
isn't any point to it, there isn't any point to it.

The biggest irritation I have with the "tree" format I chose is actually
not the name (which is trivial), it's the  part. Almost everything
else keeps the  in the ASCII hexadecimal representation, and I
should have done that here too. Why? Not because it's a  - hey, the 
binary representation is certainly denser and equivalent - but because an 
ASCII representation there would have allowed me to much more easily 
change the key format if I ever wanted to. Now it's very SHA1-specific.

Which I guess is fine - I don't really see any reason to change, and if I 
do change, I could always just re-generate the whole tree. But I think it 
would have been cleaner to have _that_ part in ASCII.

Linus
-
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: Kernel SCM saga..

[David Roundy]

On Thu, Apr 07, 2005 at 12:30:18PM +0200, Matthias Andree wrote:
> On Thu, 07 Apr 2005, Sergei Organov wrote:
> > darcs? 
> 
> Close. Some things:
> 
> 1. It's rather slow and quite CPU consuming and certainly I/O consuming
>at times - I keep, to try it out, leafnode-2 in a DARCS repo, which
>has a mere 20,000 lines in 140 files, with 1,436 changes so far, on a
>RAID-1 with two 7200/min disk drives, with an Athlon XP 2500+ with
>512 MB RAM. The repo has 1,700 files in 11.5 MB, the source itself
>189 files in 1.8 MB.
> 
>Example: darcs annotate nntpd.c takes 23 s. (2,660 lines, 60 kByte)
> 
>The maintainer himself states that there's still optimization required.

Indeed, there's still a lot of optimization to be done.  I've recently made
some improvements recently which will reduce the memory use (and speed
things up) for a few of the worst-performing commands.  No improvement to
the initial record, but on the plus side, that's only done once.  But I was
able to cut down the memory used checking out a kernel repository to 500m.
(Which, sadly enough, is a major improvement.)

You would do much better if you recorded the initial state one directory at
a time, since it's the size of the largest changeset that determines the
memory use on checkout, but that's ugly.

> Getting DARCS up to the task would probably require some polishing, and
> should probably be discussed with the DARCS maintainer before making
> this decision.
> 
> Don't get me wrong, DARCS looks promising, but I'm not convinced it's
> ready for the linux kernel yet.

Indeed, I do believe that darcs has a way to go before it'll perform
acceptably on the kernel.  On the other hand, tar seems to perform
unacceptably slow on the kernel, so I'm not sure how slow is too slow.
Definitely input from interested kernel developers on which commands are
too slow would be welcome.
-- 
David Roundy
http://www.darcs.net
-
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: Kernel SCM saga..

[Paul Jackson]

Linus wrote:
> If you want to have spaces
>  and newlines in your pathname, go wild.

So long as there is only one pathname in a record, you don't need
nul-terminators to be allow spaces in the name.  The rest of the record
is well known, so the pathname is just whatever is left after chomping
off the rest of the record.

It's only the support for embedded newlines that forces you to use
nul-terminators.

Not worth it - in my view.  Rather, do just enough hackery that
such a pathname doesn't break you, even if it means not giving
full service to such names.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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: Kernel SCM saga..

[Linus Torvalds]

On Sat, 9 Apr 2005, Paul Jackson wrote:
> 
> I must be missing something here ...
> 
> If the stat shows a possible change, then you shouldn't have to open the
> original version to determine if it really changed - just compute the
> SHA1 of the new file, and see if that changed from the original SHA1.

Yes. However, I've got two reasons for this:

 (a) it may actually be cheaper to just unpack the compressed thing than
 it is to compute the sha, _especially_ since it's very likely that
 you have to do that anyway (ie if it turns out that they _are_
 different, you need the unpacked data to then look at the
 differences).

 So when you come from your backup angle, you only care about "has it 
 changed", and you'll do a backup. In "git", you usually care about 
 the old contents too.

 (b) while I depend on the fact that if the SHA of an object matches, the 
 objects are the same, I generally try to avoid the reverse 
 dependency. Why? Because if I end up changing the way I pack objects,
 and still want to work with old objects, I may end up in the 
 situation that two identical objects could get different object 
 names.

I don't actually know how valid a point "(b)" is, and I don't think it's 
likely, but imagine that SHA1 ends up being broken (*) and I decide that I 
want to pack new objects with a new-and-improved-SHA256 or something. Such 
a thing would obviously mean that you end up with lots of _duplicate_ data 
(any new data that is repackaged with the new name will now cause a new 
git object), but "duplicate" is better than "broken".

I don't actually guarantee that "git" could handle that right, but I've
been idly trying to avoid locking myself into the mindset that "file
equality has to mean name equality over the long run". So while the system 
right now works on the 1:1 "name" <-> "content" mapping, it's possible 
that it _could_ work with a more relaxed 1:n "content" -> "name" mapping.

But it's entirely possible that I'm being a git about this.

Linus 

(*) yeah, yeah, I know about the current theoretical case, and I don't
care. Not only is it theoretical, the way my objects are packed you'd have
to not just generate the same SHA1 for it, it would have to _also_ still
be a valid zlib object _and_ get the header to match the "type + length"  
of object part. IOW, the object validity checks are actually even stricter
than just "sha1 matches".
-
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: Kernel SCM saga..

[Paul Jackson]

> in order to avoid having to worry about special characters
> they are NUL-terminated)

Would this be a possible alternative - newline terminated (convert any
newlines embedded in filenames to the 3 chars '%0A', and leave it as an
exercise to the reader to de-convert them.)

Line formatted ASCII files are really nice - worth pissing on embedded
newlines in paths to obtain.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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: Kernel SCM saga..

[Paul Jackson]

Marcin wrote:
> But what will impress you are either the price tag the 
> DB comes with or
> the hardware it runs on :-)

The payroll for the staffing to care and feed for these
babies is often impressive as well.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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: Kernel SCM saga..

[Paul Jackson]

Linus wrote:
> then git will open have exactly _one_ 
> file (no searching, no messing around), which contains absolutely nothing 
> except for the compressed (and SHA1-signed) old contents of the file. It 
> obviously _has_ to do that, because in order to know whether you've 
> changed it, it needs to now compare it to the original.

I must be missing something here ...

If the stat shows a possible change, then you shouldn't have to open the
original version to determine if it really changed - just compute the
SHA1 of the new file, and see if that changed from the original SHA1.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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: Kernel SCM saga..

[Paul Jackson]

Linus wrote:
> you need to reuse the same inode/dev numbers
> (again - I didn't worry about portability, and filesystems where those
> aren't stable are a "don't do that then") 

On filesystems that don't have a stable inode number, I use the md5sum
of the full (relative to mount point) pathname as the inode number. 

Since these same file systems (not surprisingly) lack hard links as
well, the pathname _is_ essentially the stable inode number.


Off-topic details ...

This is on my backup program, which does a full snapshot of my 90 Gb
system, including some FAT file systems, in 6 or 7 minutes, plus time
proportional to actual changes.  I have given up finding a backup
program I can tolerate, and write my own.  It stores each md5sum unique
blob exactly once, but uses the same sort of tricks you describe to
detect changes from examining just the stat information so as to avoid
reading every damn byte on the disk.  It works with smb, fat, vfat,
ntfs, reiserfs, xfs, ext2/3, ...  A single manifest file, in plain
ascii, one file per line, captures a full snapshot, disk-to-disk, every
few hours.

This comment from my backup source explains more:

# Unfortunately, fat, vfat, smb, and ncpfs (Netware) file systems
# do not have unique disk-based persistent inode numbers.
# The kernel constructs transient inode numbers for inodes
# in its cache.  But after an umount and re-mount, the inode
# numbers are all different.  So we would end up recalculating
# the md5sums of all files in any such file systems.
#
# To avoid this, we keep track of which directories are on such
# file systems, and for files in any such directory, instead
# of using the inode value from stat'ing a file, we use the
# md5sum of its path as a pseudo-inode number.  This digest of
# a file's path has improved persistance over it's transiently
# assigned inode number.  Fields 5,6,7 (files total, free and
# avail) happen to be zero on file systems (fat, vfat, smb,
# ...) with no real inodes, so we we use this fallback means
# of getting a persistent pseudo-inode if a statvfs() call on
# its directory has fields 5,6,7 summing to zero:
#   sum(os.statvfs(dir)[5:8]) == 0
# We include that dir in the fat_directories set in this case.

fat_directories = sets.Set()# set of directory paths on FAT file systems

# The Python statvfs() on Linux is a tad expensive - the
# glibc statvfs(2) code does several system calls, including
# scanning /proc/mounts and stat'ing its entries.  We need
# to know for each file whether it is on a "fat" file system
# (see above), but for efficiency we only statvfs at mount
# points, then propagate the file system type from there down.

mountpoints = [m.split()[1] for m in open("/proc/mounts")]



-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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/

2.6.12-rc2 oops PREEMPT DEBUG_PAGEALLOC sysenter_past_esp+0x3/0x75

[Steven Cole]

I got around to booting 2.6.12-rc2 here at home last night, and got several 
(12) oops.
Here is a typical one.  They all have the same trace, but occured on differing 
processes.

[18008.409586]  <1>Unable to handle kernel paging request at virtual address 
c2166000
[24538.187178]  printing eip:
[24538.187188] c0102b5c
[24538.187195] *pde = 7067
[24538.187203] *pte = 02166000
[24538.187214] Oops:  [#4]
[24538.187220] PREEMPT DEBUG_PAGEALLOC
[24538.187239] CPU:0
[24538.187244] EIP:0060:[]Not tainted VLI
[24538.187251] EFLAGS: 00010046   (2.6.12-rc2)
[24538.187274] EIP is at restore_all+0x4/0x18
[24538.187286] eax: 0282   ebx: 0006   ecx:    edx: 0001
[24538.187302] esi: 081530d8   edi: 0817f428   ebp: c2164000   esp: c2165fc8
[24538.187315] ds: 007b   es: 007b   ss: 0068
[24538.187328] Process kppp (pid: 7305, threadinfo=c2164000 task=cb69db10)
[24538.187338] Stack: 0006 541b bfb6d950 081530d8 0817f428 bfb6d928 
0036 c010007b
[24538.187366]007b ff00 c0102a9a 0060 0282 007b
[24538.187387] Call Trace:
[24538.187396]  [] sysenter_past_esp+0x3/0x75

Prior to that, I'd been running 2.6.12-rc1 without these problems.

Apologies in advance if I don't respond for additional information right
away.  I'll be away from the computer for a while today.

Anticipating one question:

[EMAIL PROTECTED] testing-2.6]$ grep PREEMPT .config
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
# CONFIG_DEBUG_PREEMPT is not set

Steven
-
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: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Adrian Bunk]

On Fri, Apr 08, 2005 at 08:31:22PM -0400, Raul Miller wrote:
> On Fri, Apr 08, 2005 at 07:34:00PM +0200, Adrian Bunk wrote:
> > If Debian was at least consistent.
> > 
> > Why has Debian a much more liberal interpretation of MP3 patent issues 
> > than RedHat?
> 
> It's impossible to treat patents consistently.
> 
> The U.S. patent office, at least, has granted patents on natural laws,
> on stuff that's already patented, on stuff with clear prior art, on
> trivial math operations and so on.  Patents are being granted so quickly
> there's no way of even knowing what's patented.
> 
> Or were you hoping that Debian would follow Red Hat's lead?


Even RedHat with a stronger financial background than Debian considered 
the MP3 patents being serious enough to remove MP3 support.

Yes, Debian can choose to put a higher risk on their distributors and 
mirrors - there's nothing wrong with this.


Note that this is a respose to Josselin's statement:

<--  snip  -->

When there are several possible interpretations, you have to pick up the
more conservative one, as it's not up to us to make the interpretation,
but to a court.

<--  snip  -->


It's simply silly to be extremely picky on copyright issues while being 
extremely liberal on patent issues - the risk of a Debian distributor 
being sued for patent violations (no matter how the lawsuit might end) 
is definitely present.


> As for this particular patent, I'm not really sure what's being patented.
>...


Which one of the 23 patents they list do you call "this particular 
patent"?


> Raul


cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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/