Dear all,
I like to use an old DOS/Clipper application through DOSEMU on a Linux
application server in a hotel. It works, but (as usual with DOS), it causes
a processor load of 100% in certain situations, while just waiting for user
interaction.
That's kind of stupid, as power saving is heavily
On Thu, 21 Jun 2007, Lennart Sorensen wrote:
On Thu, Jun 21, 2007 at 10:26:04AM -0700, [EMAIL PROTECTED] wrote:
the bios doesn't have enough capability to talk to the outside world for
updates.
Of course, although perhaps it could. More likely my thought was that
the service when it decides
> Yeah .."allow movement if it doesn't result in changing kernel-threads's cpu
> affinity" sounds good, except it is hard to implement in cpuset's
> context I think. For ex: we now have to take additional steps when
> changing 'cpus_allowed' of a cpuset such that it doesn't violate any cpu
>
On Thu, Jun 21, Olaf Hering wrote:
> On Wed, Jun 20, Andi Kleen wrote:
> > It's already annoying that they appear on x86 now -- that's for the 3button
> > emulation needed on x86 macs -- but at least don't make them default.
> > +++ linux/drivers/macintosh/Kconfig
> > @@ -2,7 +2,7 @@
> >
From: Joerg Roedel <[EMAIL PROTECTED]>
This patch adds an implementation to the svm is_disabled function to
detect reliably if the BIOS disabled the SVM feature in the CPU. This
fixes the issues with kernel panics when loading the kvm-amd module on
machines where SVM is available but disabled.
On Jun 21, 2007, jimmy bahuleyan <[EMAIL PROTECTED]> wrote:
> There, that right there, wouldn't it again require a 'nod' from all
> those who have contributed to the kernel (because at the time they did,
> the license was GPLv2 without any additions)?
That's my understanding, yes, but IANAL.
Hello,
While copying a small file over to a windows box via cifs, once again I
got something like this:
===
[ INFO: possible circular locking dependency detected ]
2.6.21.4 #8
---
cp/3088 is
Hello.
Alan Cox wrote:
Google seems to show that there is no publically available
firmware updates for Maxtor disks.
There are for some but only if you irritate the tech support people.
hours at high cpu usage There were maybe a a dozen DriveReady
SeekComplete Timeout errors
Hi,
Ph. Marek wrote:
in Oct 2000 there's been some discussion "Tux2 - evil patents sighted"
(http://www.ussg.iu.edu/hypermail/linux/kernel/0010.0/0343.html), and in Aug
2002 (http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.3/0332.html) Daniel
wrote
It's well down my list of priorities
On Thu, 2007-06-21 at 19:36 +0200, Olaf Hering wrote:
> On Wed, Jun 20, Andi Kleen wrote:
>
> >
> > It's already annoying that they appear on x86 now -- that's for the 3button
> > emulation needed on x86 macs -- but at least don't make them default.
> >
> > Signed-off-by: Andi Kleen <[EMAIL
On Thu 2007-06-21 18:01:05, Andreas Gruenbacher wrote:
> On Saturday 16 June 2007 01:49, Greg KH wrote:
> > But for those types of models that do not map well to internal kernel
> > structures, perhaps they should be modeled on top of a security system that
> > does handle the internal kernel
Udo van den Heuvel wrote:
> While copying a small file over to a windows box via cifs, once again I
> got something like this:
Again with 2.6.21.5:
===
[ INFO: possible circular locking dependency detected ]
2.6.21.5 #10
On Thu, 21 Jun 2007, Alexandre Oliva wrote:
On Jun 21, 2007, jimmy bahuleyan <[EMAIL PROTECTED]> wrote:
There, that right there, wouldn't it again require a 'nod' from all
those who have contributed to the kernel (because at the time they did,
the license was GPLv2 without any additions)?
On Thu, Jun 21, 2007 at 06:39:07AM -0300, Alexandre Oliva wrote:
> Here's an idea that just occurred to me, after all the discussions
> about motivations, tit-for-tat, authors' wishes and all.
>
> If GPLv3 were to have a clause that permitted combination/linking with
> code under GPLv2, this
On Thu, 21 Jun 2007, Oleg Nesterov wrote:
>
> Yes, force_sig() unblocks and un-ignores the signal. However, unlike
> group-wide
> signals, thread-specific signals do not convert themselves to SIGKILL on
> delivery.
> The target thread should dequeue SIGSEGV and then it calls do_group_exit().
Hi Sergei,
On Thursday 21 June 2007, Sergei Shtylyov wrote:
> Hello.
>
> Bartlomiej Zolnierkiewicz wrote:
> > [PATCH] ide: use PIO/MMIO operations directly where possible
>
> > This results in smaller/faster/simpler code and allows future optimizations.
> > Also remove no longer needed
Jeff Dike wrote:
I recieved from Guido Guenther the patch below to the TUN/TAP driver
which allows group ownerships to be effective.
It seems reasonable to me.
Looks good to me too. We'll add to my tree. In the mean time I don't
mind if one of net drv maintainers pushes it upstream.
Thanx
On Thu, Jun 21, 2007 at 07:34:45PM +0200, Alexander Wuerstlein wrote:
> On 070621 19:26, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > On Thu, Jun 21, 2007 at 06:29:17PM +0200, Alexander Wuerstlein wrote:
> > > On 070621 18:19, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > > On Thu, Jun 21, 2007 at
On Thu, Jun 21, 2007 at 10:51:06AM -0700, [EMAIL PROTECTED] wrote:
> you snippede the bit about not knowing how to stop it
I did? As far as I can tell I quoted it all. What did I miss?
> they call the section the anti-tivoization, how much more explicit can
> they get?
They could be as
been away, back now...
Tejun Heo wrote:
David Greaves wrote:
Tejun Heo wrote:
How reproducible is the problem? Does the problem go away or occur more
often if you change the drive you write the memory image to?
I don't think there should be activity on the sda drive during resume
itself.
Ack
Works for me. Thanks.
Note:
Both Masami's patch and the relay-file-read-start-pos-fix.patch I posted
earlier are required.
Masami Hiramatsu wrote:
Hi Tom,
Tom Zanussi wrote:
Could you send more info on how to reproduce the problem you're seeing?
And does this patch fix it?
The suspend and resume support only needs to be built if
CONFIG_PM is defined.
Signed-off-by: Ben Dooks <[EMAIL PROTECTED]>
Index: linux-2.6.21-quilt9/drivers/mfd/sm501.c
===
--- linux-2.6.21-quilt9.orig/drivers/mfd/sm501.c
+++
Hi,
Suspend to ram work very fine in my Toshiba M45-S355, but when laptop
return (from RAM), my network connection crash, and I need unload and
load again my sky2 module (using kernel 2.6.21.1).
My NIC is:
Marvell Technology Group Ltd. 88E8036 PCI-E Fast Ethernet Controller
(rev 10)
See
> On Wed, 20 Jun 2007 12:55:10 -0700
> "David Schwartz" <[EMAIL PROTECTED]> wrote:
> > A key is a number. A signature is a number. They are neither
> > statements nor
> > instructions. The argument that GPLv2 prohibits Tivoization is
> > really and
> > truly absurd. It has neither a legal nor a
On Thu, 21 Jun 2007, Michal Piotrowski wrote:
>
> Subject: long freezes on thinkpad t60
> References : http://lkml.org/lkml/2007/5/24/100
> Submitter : Miklos Szeredi <[EMAIL PROTECTED]>
> Handled-By : Ingo Molnar <[EMAIL PROTECTED]>
> Patch : http://lkml.org/lkml/2007/6/16/81
>
Hi,
> > Even if it does not really improve security too much it can be helpful as a
> > part of a larger system. For example around here we use a 'sbit-checker'
> > that
> > basically does a 'find' and 'chmod', which we would be able to replace by
> > this
> > patch.
>
> Something that sounds
Hi!
> >> It's really not worth getting bothered by. Truth is, big
> >> giant
> >> pathnames break lots of stuff already, both kernel and
> >> userspace.
> >
> >> Just look in /proc for some nice juicy kernel breakage:
> >> cwd, exe, fd/*, maps, mounts, mountstats, root, smaps
> >
> >Well, but we
On 06/21, Linus Torvalds wrote:
>
> On Thu, 21 Jun 2007, Oleg Nesterov wrote:
> >
> > Yes, force_sig() unblocks and un-ignores the signal. However, unlike
> > group-wide
> > signals, thread-specific signals do not convert themselves to SIGKILL on
> > delivery.
> > The target thread should
On Jun 21 2007 19:50, Jan Kandziora wrote:
>
>Dear all,
>
>I like to use an old DOS/Clipper application through DOSEMU on a Linux
>application server in a hotel. It works, but (as usual with DOS), it causes
>a processor load of 100% in certain situations, while just waiting for user
>interaction.
On Thu, 21 Jun 2007, Will Schmidt wrote:
>
> I'll second that. The obvious gotcha is that on a G5, the windfarm
> drivers don't get automatically selected, thus the fans run at full
> speed, and my office becomes a windtunnel. :-)
Since when has "default" been anything but "default". It
On Thu, 21 Jun 2007, Marco Berizzi wrote:
> > > Some RCU callback (that calls kmem_cache_free()) oopsed and
> > > panic'ed his box. [ Marco had experienced fs issues lately, so we
> > could
> > > suspect file_free_rcu() here, but I can't really tell from the stack
> > trace;
> > > BTW whats with
On Thu, 21 Jun 2007, Lennart Sorensen wrote:
On Thu, Jun 21, 2007 at 10:51:06AM -0700, [EMAIL PROTECTED] wrote:
you snippede the bit about not knowing how to stop it
I did? As far as I can tell I quoted it all. What did I miss?
they call the section the anti-tivoization, how much more
On Thu, 21 Jun 2007 10:31:53 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 21 Jun 2007, Chuck Ebbert wrote:
> >
> > A while ago I showed that spinlocks were a lot more fair when doing
> > unlock with the xchg instruction on x86. Probably the arbitration is all
> > screwed
Alexandre Oliva wrote:
> However, if GPLv3 had a permission to combine/link with code under
> GPLv2, *and* Linux (and any other projects interested in mutual
> compatibility) introduced an additional permission to combine/link
> with code under GPLv3 (or even GPLv3+, constrained by some
Hi,
I don't understand this messages available in /var/log/messages about
gconfd.
I don't use gnome (my desktop installed is KDE on Debian Etch, with
tasks="standard, kde-desktop" in boot line of installer DVD).
==
gconfd (yamane-4120): GConf server is not in use, turn-off.
gconfd
> "Mattias" == Mattias Wadenstein <[EMAIL PROTECTED]> writes:
Mattias> In theory, that's how storage should work. In practice,
Mattias> silent data corruption does happen. If not from the disks
Mattias> themselves, somewhere along the path of cables, controllers,
Mattias> drivers, buses, etc.
Chris Zankel wrote:
Jeremy,
Could you please add the ELF architecture-magic number for Xtensa (94)
when you finally submit this patch?
I guess, but I think it would be better if you just sent an incremental
patch to add it. Does my patch work OK for Xtensa?
J
-
To unsubscribe from
Hi!
> I've caught up on this thread with growing disbelief while reading the
> mails, so much that I've found it hard to decide where to reply to.
>
> So people are claiming that AA is ugly, because it introduces pathnames
> and possibly a regex interpreter. Ok, taste differs. We've got many
>
On Thu, 21 Jun 2007, Oleg Nesterov wrote:
>
> Yes, the target thread is the one that caused the SIGSEGV, it sends the signal
> to itself. entry.S:ret_from_exception should notice this signal and _dequeue_
> it, no? This signal could be stealed by signal(SIG_IGN) which runs after it
> was
On Wed, Jun 20, 2007 at 11:25:48AM -0700, Ravikiran G Thirumalai wrote:
> On Wed, Jun 20, 2007 at 09:36:30AM -0400, Len Brown wrote:
> > On Wednesday 20 June 2007 04:49, Andreas Herrmann wrote:
> > > On Tue, Jun 19, 2007 at 11:38:02PM -0400, Len Brown wrote:
> > > > On Tuesday 19 June 2007 18:50,
Hi David,
On Thu, 21 Jun 2007 22:47:12 +0800, David Woodhouse wrote:
> On Thu, 2007-06-21 at 11:33 +0200, Jean Delvare wrote:
> > OK. This leads me to a question: is it OK for me to add support for my
> > non-input device to inputattach, or is a separate, dedicated helper
> > tool preferred? Both
> So much for "Land of the free". :(
That was always just a typo. Its the Land of the Fee
-
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
This patch changes the test for the thread pid from >= 0 to > 0.
When the saa8134 driver initialization fails after a certain point,
it goes through the complete shutdown process for the driver. Part
of shutting it down includes tearing down the thread for tv audio.
The test for tearing
On Thu, 21 Jun 2007, Eric Dumazet wrote:
>
> This reminds me Nick's proposal of 'queued spinlocks' 3 months ago
>
> Maybe this should be re-considered ? (unlock is still a non atomic op,
> so we dont pay the serializing cost twice)
No. The point is simple:
IF YOU NEED THIS, YOU ARE
Hello Luca,
Sorry for delay,
Ok, it makes sense :)
Name (FBUF, Package (0x06)
{
0x03,
CPUF,
CHAF,
PWRF,
CHPF,
CH2F
})
Clearly the first number is not the number of available readings (though
it matches the count in the other DSDTs I've seen); don't know what it
is :|
The loop to disable slabs can use step 8. Looks a bit strange the way it
is now.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
mm/slub.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.22-rc4-mm2/mm/slub.c
On Thu, 2007-06-21 at 19:46 +0200, Alexander Wuerstlein wrote:
> On 070621 19:33, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > On Thu, 2007-06-21 at 19:25 +0200, Alexander Wuerstlein wrote:
> > > On 070621 19:21, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > > > On Thu, 2007-06-21 at 18:02
Jesper Juhl wrote:
On 20/06/07, Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
This trivial patch adds braces over a one-line
loop. That makes code...well... little bit
convenient for (possible) further modifications.
That's generally not done.
It's even in Documentation/CodingStyle :
"
Do not
On Thu, Jun 21, Linus Torvalds wrote:
>
>
> On Thu, 21 Jun 2007, Will Schmidt wrote:
> >
> > I'll second that. The obvious gotcha is that on a G5, the windfarm
> > drivers don't get automatically selected, thus the fans run at full
> > speed, and my office becomes a windtunnel. :-)
>
> Since
On 06/21, Linus Torvalds wrote:
>
> On Thu, 21 Jun 2007, Oleg Nesterov wrote:
> >
> > Yes, the target thread is the one that caused the SIGSEGV, it sends the
> > signal
> > to itself. entry.S:ret_from_exception should notice this signal and
> > _dequeue_
> > it, no? This signal could be
Am Donnerstag, 21. Juni 2007 20:26 schrieb Jan Engelhardt:
>
> Of course there may be hacks that try to figure out if a DOS window is
> idle, waiting for user input. (Seems like a new invention in Windows 2000
> and up). Since dosemu and all the emulators are not running a genuine
> Microsoft DOS
Hi again,
Of course it is not there because I removed it myself :/ The "sensors" command
will just produce "general parse error" this is because of the unknown device
class (imho). So I removed that and forgot. Well now I have the sysfs files:
/sys/class/hwmon/hwmon2/device/:
bus
Linus Torvalds:
> I suspect that this is about a few hundred lines of code (and a lot of
> testing). And you can emulate O_DIRECT behavior with it, along with
> splice (only for page-cache entities, though), and a lot of other
> off-by-one uses.
( http://lwn.net/2002/0516/a/lt-async.php3 )
I
On Jun 21 2007 21:00, Jan Kandziora wrote:
>I know it's a crude idea for everyday Linux processes, but for
>dosemu driven applications, which behave badly in a multitasking OS
>*and* for which source code isn't available, it may be worth to
>discuss.
Would dosbox do? (it does busy-loops too,
Am Donnerstag, 21. Juni 2007 00:46 schrieb H. Peter Anvin:
> Dr. David Alan Gilbert wrote:
> > What happens with the (sick) case of spaces in directory names?
> > Also is it really nicely defined that there is no way to put a space
> > in an option in any of the filesystems? I suppose someone
>
Hi,
I think you might be interested in following patch, which implements _ACPI_
driver for the same hardware...
It is only "proof of concept" at the moment, but it does main thing -- reads
hwmon device using ACPI interfaces.
Regards,
Alex.
Rudolf Marek wrote:
> Hi again,
>
> Of course it is
On 6/20/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
Display the current usage and limit in a more user friendly manner. Number
of pages can be confusing if the page size is different. Some systems
can choose a page size of 64KB.
I'm not sure that's such a great idea. "Human-friendly"
Hans-Peter Jansen wrote:
>> That's already handled just fine:
>>
>> bash-3.1$ mkdir /tmp/'Jag är: \
>> en liten mask'
>> bash-3.1$ sudo mount -t tmpfs none '/tmp/Jag är: \
>> en liten mask'/
>> bash-3.1$ tail -1 /proc/mounts
>> none /tmp/Jag\040är:\040\134\012en\040liten\040mask tmpfs rw 0 0
>>
David Schwartz wrote:
On Wed, 20 Jun 2007 12:55:10 -0700
"David Schwartz" <[EMAIL PROTECTED]> wrote:
A key is a number. A signature is a number. They are neither
statements nor
instructions. The argument that GPLv2 prohibits Tivoization is
really and
truly absurd. It has
On 2007-06-21T20:33:11, Pavel Machek <[EMAIL PROTECTED]> wrote:
> inconvenient, yes, insecure, no.
Well, only if you use the most restrictive permissions. And then you'll
suddenly hit failure cases which you didn't expect to, which can
possibly cause another exploit to become visible.
> I
Peter Rabbitson wrote:
>
> I have captured dmesg output without mem[5], with mem=3900M[6] and
> mem=2048M[7].
>
What does /proc/mtrr look like in the two cases?
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On Thu, 21 Jun 2007, Pavel Machek wrote:
If that is the only way to implement AA on top of SELinux - and so far,
noone has made a better suggestion - I'm convinced that AA has technical
merit: it does something the on-disk label based approach cannot handle,
and for which there is demand.
On 6/21/07, Rudolf Marek <[EMAIL PROTECTED]> wrote:
> Ok, it makes sense :)
>
> Name (FBUF, Package (0x06)
> {
> 0x03,
> CPUF,
> CHAF,
> PWRF,
> CHPF,
> CH2F
> })
>
> Clearly the first number is not the number of available readings (though
> it matches the count in the
On 2007-06-21T12:30:08, [EMAIL PROTECTED] wrote:
> well, if you _really_ want people who are interested in this to do weekly
> "why isn't it merged yet you $%#$%# developers" threads that can be
> arranged.
>
> the people who want this have been trying to be patient and let the system
> work.
On Jun 21, 2007, [EMAIL PROTECTED] wrote:
> On Thu, 21 Jun 2007, Alexandre Oliva wrote:
>> On Jun 21, 2007, [EMAIL PROTECTED] wrote:
>>
>>> no, one of the rules for the network is that the software must be
>>> certified,
>>
>> In this case you might have grounds to enforce this restriction of
On Jun 21, 2007, Bernd Schmidt <[EMAIL PROTECTED]> wrote:
> I went and made some comments on the draft, and they appear to no
> longer be there a few days later.
This would be very bad. Please let me know what they were about and
I'll try to figure out what happened.
Did you by any chance file
On Jun 21, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:
>> On Wed, 20 Jun 2007 12:55:10 -0700
>> "David Schwartz" <[EMAIL PROTECTED]> wrote:
>> > A key is a number. A signature is a number. They are neither
>> > statements nor
>> > instructions. The argument that GPLv2 prohibits Tivoization
On Thu, 21 Jun 2007, Linus Torvalds wrote:
>
> We don't do nesting locking either, for exactly the same reason. Are
> nesting locks "easier"? Absolutely. They are also almost always a sign of
> a *bug*. So making spinlocks and/or mutexes nest by default is just a way
> to encourage bad
On Thu, 21 Jun 2007, Rafael J. Wysocki wrote:
> > I'll see if I can reproduce your problem here.
>
> Yes, I can. It's only necessary to load usb-storage (without any devices
> actually using it) and it fails device_suspend() immediately (I don't think
> it's freezer-related).
>
> I've got the
On 6/7/07, Jesse Barnes <[EMAIL PROTECTED]> wrote:
On some machines, buggy BIOSes don't properly setup WB MTRRs to
cover all available RAM, meaning the last few megs (or even gigs)
of memory will be marked uncached. Since Linux tends to allocate
from high memory addresses first, this causes the
On Thu, 21 Jun 2007, Lars Marowsky-Bree wrote:
> A veto is not a technical argument. All technical arguments (except for
> "path name is ugly, yuk yuk!") have been addressed, have they not?
AppArmor doesn't actually provide confinement, because it only operates on
filesystem objects.
What you
On 21 Jun 2007, Miklos Szeredi said:
> I'm working on this actually. See this (and related patches) in -mm:
>
>
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/broken-out/unprivileged-mounts-add-user-mounts-to-the-kernel.patch
>
> This solves the
On Sunday 17 June 2007, Sergei Shtylyov wrote:
[ ... ]
> >>>Index: b/drivers/ide/pci/alim15x3.c
> >>>===
> >>>--- a/drivers/ide/pci/alim15x3.c
> >>>+++ b/drivers/ide/pci/alim15x3.c
> >>>@@ -594,7 +594,7 @@ out:
> >>> *
On Sunday 17 June 2007, Masatake YAMATO wrote:
> > Please re-submit this fix in the form of a patch so I can merge it.
>
> Here it is.
Applied but please remember to always include patch description when
sending the improved version of the patch. This time I fixed it manually
to speed up the
On Jun 21, 2007, [EMAIL PROTECTED] (Lennart Sorensen) wrote:
> Apparently the only restrictions ever permitted are the ones the FSF
> thinks of.
Where does this nonsensical idea come from? How does it follow that,
from FSF offering a licensing option to authors, you conclude that
nobody could
On Jun 21, 2007, Andrew McKay <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>> how can the server tell if it's been tampered with?
> I agree with this statement.
Err... That's a question, not a statement ;-)
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin
On Wed, Jun 20, 2007 at 06:01:23PM +0100, Alan Cox wrote:
>
> Its unlikely the command got lost. The IRQ could have done but the error
> path tries to spot that case by reading the status register - which
> hangs. So in theory it could be a lost IRQ and if the reset works we'll
> find that out.
Hi,
I've found a preemption problem in kernel/rtmutex.c:649. The BUG_ON
listed in the patch below makes sure a preemption event hasn't occurred since
the thread last checked the owner of the lock. If it did happen and the
current task is now the owner, it asserts with BUG_ON. With
Hi!
> >>The code has improved, and continues to improve, to meet all the coding
> >>style feedback except the bits which are essential to AA's function
> >
> >Which are exactly the bits Christoph Hellwig and Al Viro
> >vetoed. http://www.uwsg.iu.edu/hypermail/linux/kernel/0706.1/2587.html
> >. I
I'd like to make a read-only /proc file which supports inotify -- that
is, the kernel can send change notifications to userland via the
inotify mechanism. I've found fsnotify_modify() (in
include/linux/fsnotify.h) which seems to do what I want, but it takes
a struct dentry * -- how can I get a
On Jun 21, 2007, Andrew McKay <[EMAIL PROTECTED]> wrote:
> A balance of freedom to the licensee and the licenser. It's my
> opinion that GPLv3 potentially shifts the balance too far to the
> licensee.
It's more of a balance of freedom between licensee and licensee,
actually. It's a lot about
> Fengwei Yin napsal(a):
> > Hi,
> > In function tsdev_event() of drivers/input/tsdev.c,
> > conversion from usec to milisec is like:
> >client->event[client->head].millisecs =
> > time.tv_usec / 100;
> > ~~ should be 1000?
>
> Seems so. James CCed.
Thats my old
On Jun 21, 2007, [EMAIL PROTECTED] wrote:
> On Thu, 21 Jun 2007, Lennart Sorensen wrote:
>> You can't use this code if you cooporate with anyone that requires
>> DRM systems.
> I think their earlier versions did say this.
Show me a GPLv3 draft that did it?
Start here, section 3:
On 2007-06-21T15:42:28, James Morris <[EMAIL PROTECTED]> wrote:
> > A veto is not a technical argument. All technical arguments (except for
> > "path name is ugly, yuk yuk!") have been addressed, have they not?
> AppArmor doesn't actually provide confinement, because it only operates on
>
On Thu, Jun 21, 2007 at 09:13:11AM +0200, Peter Zijlstra wrote:
> On Wed, 2007-06-20 at 23:37 -0700, Keshavamurthy, Anil S wrote:
> > On Thu, Jun 21, 2007 at 08:29:34AM +0200, Peter Zijlstra wrote:
> > > On Wed, 2007-06-20 at 23:11 -0700, Arjan van de Ven wrote:
> > > > Peter Zijlstra wrote:
> > >
On Jun 21, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva wrote:
>> However, if GPLv3 had a permission to combine/link with code under
>> GPLv2, *and* Linux (and any other projects interested in mutual
>> compatibility) introduced an additional permission to combine/link
>>
On Thursday, June 21, 2007 12:40:58 Yinghai Lu wrote:
> On 6/7/07, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > On some machines, buggy BIOSes don't properly setup WB MTRRs to
> > cover all available RAM, meaning the last few megs (or even gigs)
> > of memory will be marked uncached. Since Linux
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Umm. i386 spinlocks could and should be *one*byte*.
>
> In fact, I don't even know why they are wasting four bytes right now:
> the fact that somebody made them an "int" just wastes memory. All the
> actual code uses "decb", so it's not even a
On Thu, 21 Jun 2007, Alexandre Oliva wrote:
On Jun 21, 2007, [EMAIL PROTECTED] wrote:
On Thu, 21 Jun 2007, Alexandre Oliva wrote:
On Jun 21, 2007, [EMAIL PROTECTED] wrote:
no, one of the rules for the network is that the software must be
certified,
In this case you might have grounds to
On Jun 21, 2007, [EMAIL PROTECTED] wrote:
> this is standard dual-licensing, not special just becouse both
> licenses are GPL versions
No, seriously, it's not, it's quite different.
If you dual-license your code between GPLv2 and GPLv3, I could combine
your code with code under GPLv3,
Alexandre Oliva wrote:
On Jun 21, 2007, Andrew McKay <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
how can the server tell if it's been tampered with?
I agree with this statement.
Err... That's a question, not a statement ;-)
Sorry, that's what happens when one types before
Hi!
> > I believe AA breaks POSIX, already. rename() is not expected to change
> > permissions on target, nor is link link. And yes, both of these make
> > AA insecure.
>
> AA is supposed to allow valid access patterns, so for non-buggy apps +
> policies, the rename will be fine and does not
On 21 Jun 2007, Neil Brown stated:
> I have that - apparently naive - idea that drives use strong checksum,
> and will never return bad data, only good data or an error. If this
> isn't right, then it would really help to understand what the cause of
> other failures are before working out how to
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> If somebody can actually come up with a sequence where we have
> spinlock starvation, and it's not about an example of bad locking, and
> nobody really can come up with any other way to fix it, we may
> eventually have to add the notion of "fair
On 6/21/07, Alexey Starikovskiy <[EMAIL PROTECTED]> wrote:
Hi,
I think you might be interested in following patch, which implements _ACPI_
driver for the same hardware...
It is only "proof of concept" at the moment, but it does main thing -- reads
hwmon device using ACPI interfaces.
Well,
On Thu, 21 Jun 2007, Ingo Molnar wrote:
>
> I can understand why no data is saved by this change: gcc is aligning
> the next field to a natural boundary anyway and we dont really have
> arrays of spinlocks (fortunately).
Actually, some data structures could well shrink.
Look at "struct
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> (And no, on 32-bit x86, we don't allow more than 128 CPU's. I don't
> think such an insane machine has ever existed).
and if people _really_ want to boot a large-smp 32-bit kernel on some
new, tons-of-cpus box, as a workaround they can enable the
On Jun 21, 2007, Al Viro <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 21, 2007 at 06:39:07AM -0300, Alexandre Oliva wrote:
>> - the kernel Linux could use code from GPLv3 projects
> ... and inherit GPLv3 additional restrictions. No.
Respecting the wishes of the author of that code. Are you
Alexandre Oliva wrote:
On Jun 21, 2007, Andrew McKay <[EMAIL PROTECTED]> wrote:
A balance of freedom to the licensee and the licenser. It's my
opinion that GPLv3 potentially shifts the balance too far to the
licensee.
It's more of a balance of freedom between licensee and licensee,
On Thu, 21 Jun 2007, Ingo Molnar wrote:
>
> * Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > If somebody can actually come up with a sequence where we have
> > spinlock starvation, and it's not about an example of bad locking, and
> > nobody really can come up with any other way to fix it,
701 - 800 of 979 matches
Mail list logo
