Re: Would like to form a pool of Linux copyright holders for faster GPL enforcement against Anthrax Kernels
On 19.05.2013 11:57, luke.leighton wrote: On Sun, May 19, 2013 at 10:12 AM, Ian Stirling wrote: On 18.05.2013 19:27, luke.leighton wrote: question: what is the procedure for having that licensing explicitly added to the linux kernel sources? Fork the kernel, and put it up on a repo somewhere that says you're trying to get it all as GPL3. i wish to know the procedure by which my formally and publicly announced release of all linux kernel contributions under the dual licenses of GPLv2 and GPLv3+ may be entered - formally - upstream and into the linux kernel sources being maintained on git.kernel.org Umm - that was my point - though I did not make it explicitly. Either there is a policy change, and it is decided to allow such dual-licenced code in the repo, or your code does not get checked in, as it does not have a compatible licence. If Linus takes the view that he does not wish to allow this - and the project is not forked - you actually have to do the above. Sure - you have the right to licence code you write any way you choose. Linus (and the people involved in maintaining the kernel) have the right to not accept your code under that licence. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
A new, cheap low-power motherboard - how to pick?
I was wanting to upgrade from my K7S5A (Socket A, duron 1300) to something with integrated USB2 and net. The K7S5A was poor in a few ways - but at least showed that it was possible for it to hit 30-32W idle, using athcool, though the network card kept wedging, and sound diddn't work in that mode. The very few reviews I can find seem to indicate that 'CoolnQuiet' doesn't really help much. Can anyone suggest where I should start looking? (at a total budget of $US100 for motherboard + processor or so). I'm on a quest for replacing any items in the home with low power ones, and energy saving versions, as they need replaced. My bills are too high. My first choice - the K7S41GX - diddn't actually work out in that athcool doesn't work at all (trying to raise the energy to look in the chipset datasheet if I can find it) Many thanks. Ian Stirling. - 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: loop device corruption in 2.4.6
> > Mark Swanson wrote: > > I get repeatable errors with 2.4.6 patched with the international encryption > > patch patch-int-2.4.3.1.bz2 when building loop device filesystems on top of > > Reiserfs. > > And the block size thing is not the only thing wrong with international > crypto patch. The whole cryptoapi thing is just bloat that does not belong > in kernel. Cipher name string to number code mappings should be done in user > space instead of kernel. And the ice on the cake is that cryptoapi ciphers Why is this any more evil than protocol names in kernel, or filesystem names in kernel. The consequences of getting the cipher wrong are often worse than that of getting the filesystem wrong. > Loop-AES is a superior replacement for international crypto patch, for more > information about loop-AES, see this announcement: That has a fraction of the features. And no, I'm not completely happy with crypto-API, I managed to get it to corrupt a test FS with a few weeks stress-test a while back. - 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: Cosmetic JFFS patch.
> > > Is this (printing out versions. etc) really a big deal so we should add stuff > like "/proc/xxx", KERN_ to make things more complicated? It sounds to me > like to make the kernel "smaller" we'd actually end up with adding more code > and complexity to it. And quite frankly, if people don't read MAINTAINERS, > they won't read /proc/maintainers either. That was why I had the thought of doing it at compile time, based on a magic list of versions only updated by Linus. As I've been told that this won't work very well due to some people having the temerity to disagree with him on driver versions shipped :), something more flexible is needed. I can't think of a neat way to do this, without knowing the source tree the kernel came from though. I think at least knowing what drivers are not stock might be useful. Perhaps make distversion xxx would add another string to KERNELRELEASE, setting a major releases "stock" drivers, and letting anything that changes thereafter have a higher default display level. - 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: Cosmetic JFFS patch.
> > Linus Torvalds wrote: > > Things like version strings etc sound useful, but the fact is that the > > only _real_ problem it has ever solved for anybody is when somebody thinks > > they install a new kernel, and forgets to run "lilo" or something. But > > even that information you really get from a simple "uname -a". > > > > Do we care that when you boot kernel-2.4.5 you get "net-3"? No. Do we care > > that we have quota version "dquot_6.4.0"? No. Do we want to get the > > version printed for every single driver we load? No. It would be nice to show driver version for every single non-stock driver we load though. Perhaps a list of versions in the stock kernel build, stored somewhere, that shouldn't be patched by anyone, but only change with official releases. At compile time, if the driver version string is different from the 'blessed' version, it prints it's version, and possibly more. > As Alan said, driver versions are incredibly useful. People use update > their drivers over top of kernel drivers all the time. Vendors do it > too. "Run dmesg and e-mail me the output" is 1000 times more simple for > end users. - 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: Where is check for superuser in TCP port bind.
> > Obviously (to me) this check is in tcp_v4_get_port(). > But, I can't find it, or perhaps it's better hidden than I thought. > Or maybe I'm just very confused. > Any help would be most welcome. The above poster was of course deeply stupid, and could have done with more sleep :) It's in net/ipv4/af_inet.c I was looking for some way of letting users own devices, so they can do some subset of the operations reserved for root on their device. Further reading led to "route by owner" in netfilter, but it's not quite it. This would let me do something like: ifconfig eth0:www 1.2.3.4 route add default 1.2.3.4 -user www But would still not let www bind low ports on eth0:www. There seem to be a few ways to do this. Teach capable() about owned routes. Make interfaces/aliases directly ownable, add CAP_NET_BIND_ANY so you can only bind to an interface you own, or if you have CAP_NET_BIND_ANY. You need CAP_NET_BIND_ANY to chown an interface. The second way seems cleaner to me. Any comments? - 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/
Where is check for superuser in TCP port bind.
Obviously (to me) this check is in tcp_v4_get_port(). But, I can't find it, or perhaps it's better hidden than I thought. Or maybe I'm just very confused. Any help would be most welcome. - 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/
Loopback crypt.
Is there any way to delete the key of an existing loopback encrypted device, and have it block, until a key is reloaded? Of course any cached pages would need deleted, and dirty ones flushed first. To enable things like deleting keys from memory, before suspend-to-disk, or forcing users of devices to verify identitiy, on various events. - 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: Lid support.
> > Hi! > > > I assume there is no generic APM support for lid-close? > > My BIOS (P100 DEC CTS5100 Hinote VP) has no way to do anything other > > than beep, when the lid is closed, so I'm using a hack that polls the > > ct65548 video chips registers to find when the BIOS turns the LCD off, > > so I can do whatever. > > > > Or is there a better wya? > > Yes, going ACPI. But you'll need current acpi, not the one in 2.4.3 Is ACPI really likely to be in a Sep 95 laptop? Isn't it usually mentioned in the BIOS? - 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] Single user linux
> > On Thu, 26 Apr 2001, Ian Stirling wrote: > > > Also, there is another reason. > > If you'r logged in as root, then any exploitable bug in large programs, > > be it netscape, realplayer, wine, vmware, ... means that the > > cracker owns your machine. > Heh. You receive all your email on your root account? Nope. For historical reasons (I gave out this address before I started using linux) and mail to root here does not actually go to root. - 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] Single user linux
> > > On Thursday, April 26, 2001, at 07:03 AM, <[EMAIL PROTECTED]> wrote: > > he owns the computer, he may do anything he wants. > Any OS worth its weight in silicon will make a distinction between > blessed and unblessed users. It can be phrased in different ways -- > root vs. non-root, admin vs. non-admin. But no one should EVER log in > to a machine as root. Period. (1) Also, there is another reason. If you'r logged in as root, then any exploitable bug in large programs, be it netscape, realplayer, wine, vmware, ... means that the cracker owns your machine. If they are not, then the cracker has to go through another significant hoop, in order to get access to the machine. For optimal security, you can do things like running netscape and other apps under unpriveledged users, where they only have access to their own files. (Note, netscape/.. are just used as examples, I'm not saying they are more buggy than others, just large, and hard to get bug-free) - 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/
Lid support.
I assume there is no generic APM support for lid-close? My BIOS (P100 DEC CTS5100 Hinote VP) has no way to do anything other than beep, when the lid is closed, so I'm using a hack that polls the ct65548 video chips registers to find when the BIOS turns the LCD off, so I can do whatever. Or is there a better wya? - 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: Idea: Encryption plugin architecture for file-systems
> > Hello, ftp://www.kerneli.org/pub/linux/kerneli/ For idea encryption, you just use losetup -e idea /dev/loop0 /filesystem Password: whatever mke2fs /dev/loop0 mount /dev/loop0 - 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: IP Acounting Idea for 2.5
> > Manfred Bartz responded to > > Russell King <[EMAIL PROTECTED]> who writes: > > You just illustrated my point. While there is a reset capability > > people will use it and accounting/logging programs will get wrong > > data. Resetable counters might be a minor convenience when debugging > > but the price is unreliable programs and the loss of the ability of > > several programs to use the same counters. > > You of course, are commenting from the fact that your applications are > stupid, written poorly, and cannot handle 'wrapped' data. Take MRTG > Similarly, if my InPackets are at 102345 at one read, and 2345 the next > read, > and I know that my counter is 32 bits, then I know i've wrapped and can do I think the point being made is that if InPackets are at 102345 at one read, and 2345 the next, and you know it's a 32 bit counter, it's completely unreliable to assume that you have in fact recieved 4294867295 packets, if the counter can be zeroed. You can say nothing other than at least 2345 packets, at most 2345+n*2^32 have been got since you last checked. - 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/
Dumping memory of a running process?
Is there a way to dump the memory of any process without stopping, or modifying it? Obviously normally stopping it would be the right thing to do, but is it possible, and if so, is there a handy tool? - 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: Microsoft begining to open source Windows 2000?
> Not a chance. First your company must have at least 1500 licences and > you can't modify any code... which implies that you can't rebuild either... You can modify your compiler, so that it accepts patches (with no context) and completely rewrite anything that needs modified. The modified source would never be stored anywhere. - 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: PS/2 Mouse/Keyboard conflict and lockup
> > > I'm not sure whether this is related to the ominous ps/2 mouse bug > > you have been chasing, but this problem is 100% reproducible and > > very annoying. I'm also seeing a ps/2 mouse bug, with 2.4.0-pre5 (I think) on a CS433 (486/33 laptop) Freezes after some time in X, killing keyboard. Is there a generic approach to finding where this sort of problem lies? I note that there were problems in the 2.0.n era, that were fixed in 2.0.n+3 or so (I think 30), on the ct475, that were similar. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Abysmal RAID 0 performance on 2.4.0-test10 for IDE?
> > On Tue, 26 Dec 2000, Felix von Leitner wrote: > > Thus spake Rik van Riel ([EMAIL PROTECTED]): > > > > One more detail: top says the CPU is 50% system when reading from either > > > > one of the disk or raid devices. That seems awfully high considering > > > > that the Promise controller claims to do UDMA. > > > > > > > > Any comments? > > > Your program reads in data at 30MB/second, on a memory bus > > > that most likely supports something like 60 to 100MB/second. > > > > 100. > > So that's 30% for the UDMA controller and maybe > 30% for the CPU (if your program reads in all the > data). Where are you getting 100MB/s? The PCI bus can move around 130MB/sec, but RAM is lots faster. A single PC100 DIMM can move 800MB/sec. This P100 laptop I'm typing on gets better than 100MB/s ram reads. Anyway, in clarification, Rik mentioned that two reads from different disk (arrays?) on the same controller at the same time get more or less the same speed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: About Celeron processor memory barrier problem
> > [EMAIL PROTECTED] (Tim Wright) wrote on 24.12.00 in ><[EMAIL PROTECTED]>: > > > On Sun, Dec 24, 2000 at 11:36:00AM +0200, Kai Henningsen wrote: > > > There was a similar thread to this recently. The issue is that if you > > choose the wrong processor type, you may not even be able to complain. > > Hmm ... I think I can see ways around that (essentially similar to the 16 > bit bootstrap code), but it may indeed be more trouble than it's worth. What about a simple solution, "Ok, Booting the kernel for i486+fpu and above." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Laptop system clock slow after suspend to disk. (2.4.0-test9/hinote VP)
I've not noticed this on earlier kernel versions, is there something silly I'm missing that's making my DEC hinote VP (p100 laptop)s system clock slow by a factor of five or so after resume? Not the CPU or cmos clock, only the system clock. Thoughts welcome. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: User based routing?
> > On Mon, Dec 18, 2000 at 07:46:51PM +0000, Ian Stirling wrote: > > Are there any patches floating around? > > Basically to allow for example a server to dial out to ISP's on behalf > > of users, and give them full control over that interface. > > I know about UML, and it's not quite suited. > > I've not found anything searching archives, but maybe it's out there. > > Sounds like you're looking for masqdialer. It doesn't give full control > to users (why should it), but it allows users to select from multiple > ISPs. Looking at it, it won't quite work. I'm looking for a way to let users logged onto the server open connections that they "own", that othere users can't use. Not ways of connecting other machines over shared ppp/... links. May be usefull for other things though, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
User based routing?
Are there any patches floating around? Basically to allow for example a server to dial out to ISP's on behalf of users, and give them full control over that interface. I know about UML, and it's not quite suited. I've not found anything searching archives, but maybe it's out there. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Booting on the wrong processor.
I have just had a frustrating experience, solely blameable on my own stupidity. Basically, I'd been assuming that stopping after "booting kernel" was due to some corruption, rather than the obvious, of checking that I had indeed selected the right processor when compiling. What about "booting the kernel for i386" ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PCMCIA-USB (non-cardbus). Any support pending?
Along with many others, I have an older laptop. I also notice the large number of USB things released, some of which I'd like to connect to it. Is there hardware around? Is anyone working on drivers? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG REPORT] Conflict between Tulip driver w/ LinkSys 100LNE and EEPro
> The problem: I can't have the Tulip and EEPro drivers loaded at the same > time. If I have the Tulip driver loaded, and I load the EEPro driver, the > self check fails with 0x and complains that I don't have the card in > a bus master slot. If I have the EEPro driver loaded and the ether tested > as working, and I insmod the tulip driver, this happens: > . > Oct 18 10:13:33 zephyr kernel: eepro100: wait_for_cmd_done timeout! > Oct 18 10:13:33 zephyr kernel: eepro100: wait_for_cmd_done timeout! > Oct 18 10:14:02 zephyr last message repeated 27 times > Oct 18 10:14:02 zephyr last message repeated 27 times > Oct 18 10:14:04 zephyr kernel: eepro100: wait_for_cmd_done timeout! I don't have exact details, but a similar thing happened to me. Oct 16 16:46:54 mauve kernel: eth0: Intel Corporation 82557 [Ethernet Pro 100], 00:A0:C9:10:63:9C, IRQ 9. Oct 16 16:46:54 mauve kernel: Board assembly 645477-004, Physical connectors present: RJ45 BNC AUI Oct 16 16:46:54 mauve kernel: Primary interface chip 80c24 PHY #0. Oct 16 16:46:54 mauve kernel: General self-test: passed. Oct 16 16:46:54 mauve kernel: Serial sub-system self-test: passed. Oct 16 16:46:54 mauve kernel: Internal registers self-test: passed. Oct 16 16:46:54 mauve kernel: ROM checksum self-test: passed (0x49caa8d6). Oct 16 16:46:54 mauve kernel: Receiver lock-up workaround activated. Oct 16 16:46:54 mauve kernel: eth1: Intel Corporation 82557 [Ethernet Pro 100] (#2), 00:A0:C9:10:82:37, IRQ 11. Oct 16 16:49:10 mauve kernel: Linux Tulip driver version 0.9.9 (August 11, 2000) Oct 16 16:49:10 mauve kernel: eth2: Digital DS21140 Tulip rev 34 at 0xf000, 00:40:05:30:BF:8F, IRQ 10. Oct 16 16:49:10 mauve kernel: eth2: EEPROM default media type Autosense. Oct 16 16:49:10 mauve kernel: eth2: Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block. Oct 16 16:49:10 mauve kernel: eth2: MII transceiver #8 config 3100 status 7849 advertising 01e1. The Tulip card wouldn't respond, or send pings, and IIRC, came up with 3 errors per attempt to send a packet. Both eepro100's worked fine. It's a netgear FA310TX If it'd be handy, I could do it again, and check exact results if needed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Device Driver
> > > > I take it then that you never use a hard drive in any of your systems on > > the grounds that it contains non-open source firmware which may affect > > the security of your system? ;) Tell me, what do you use to store all > > those Linux applications on? > > Your ATA drive can't tell you kernel what to do. I've seen some nice > modules that do very nasty things to your system, and I was suprised that > it was even possible. Sure a hard drive can. A thingy that parses partition tables, looks for lilo, finds the kernel, and adds bits, before the rest of the system has even checked RAM, is quite possible. No, it's not as easy to do, but it's not impossible either. As can a video card, simply dig around in main memory when idle, looking for interesting stuff, and changing it as desired. When was the last time you checked the network boot PROM holds the code you thought it did, > > For my own system : I don't care. But I can imagine that there are people > out there that do care about these kind of issues. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
> > On Fri, Oct 13, 2000 at 04:19:49AM +, Ingo Rohloff wrote: > 2.4 has already broken backwards compatibility to 2.2 (IV changed > from disk absolute to relative). When you change it now (before 2.4.0) > it is relatively painless. I think the change is a good idea. I've been away from the list for a while, so this has probably been discussed. But, it seems to me that being able to have a different IV for each filesystem would be a good thing, but having it depend on something as volatile as sector of the disk, seems bad. What about the first block of the underlying file holding an IV? Then, if a loopback mount attempt finds a valid IV block at the start (heavily CRC'd or similar, so the likelyhood of it ever finding false magic is negligable (Say 10^-50)) it mounts the filesystem, using the IV found. Please tell me where the glaring error is :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
