2.4.4 bug...
I found a bug in the patches for kernel 2.4.4. When i use 2.4.4 clean, with no patches hde: IBM-DTLA-307020, ATA DISK drive hde: 40188960 sectors (20577 MB) w/1916KiB Cache, CHS=39870/16/63, UDMA(100) then, using kernel 2.4.4 with ac11 patch... hde: IBM-DTLA-307020, ATA DISK drive hde: 40188960 sectors (20577 MB) w/1916KiB Cache, CHS=39870/16/63, UDMA(44) why the hard-disk is found at udma 3?? -- -=[/home/slump]=- hdparm -t /dev/hde /dev/hde: Timing buffered disk reads: 64 MB in 2.29 seconds = 27.95 MB/sec -- -=[/home/slump]=- hdparm -X69 /dev/hde /dev/hde: setting xfermode to 69 (UltraDMA mode5) -=[/home/slump]=- hdparm -t /dev/hde /dev/hde: Timing buffered disk reads: 64 MB in 1.84 seconds = 34.78 MB/sec My machine is an athlon 950, with abit-kt7raid motherboard. My hard-disk is an IBM DTLA 307020 20gb UDMA 5. thank's to all ;) Guilherme M. Schroeder [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: [kbuild-devel] Re: CML2 design philosophy heads-up
On Mon, 21 May 2001, Jakob Østergaard wrote: > On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote: > > > > im not installing python2 from source just so i can run some new config > > utility. > > python2 will be in rawhide when 2.5 development requires it, if I'm not much > mistaken. Alan said someone is rewriting in C, so the python2 requirement is already becoming a non-problem. -Mike (don't like requirement, but don't think it's a big hairy deal either) - 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/
No Subject
Ph. Marek writes: > in fs/devfs/util.c is > void __init devfs_make_root (const char *name) > which is wrong as pivot_root allows changing the root-device in the runtime. > > I think it should be > void __init devfs_make_root (const char *name) > and get called by > fs/super.c: > asmlinkage long sys_pivot_root(const char *new_root, const char *put_old) > after > chroot_fs_refs(root,root_mnt,new_nd.dentry,new_nd.mnt); > error = 0; > > Is that correct? No, because devfs_mk_root() only ever needs to called from mount_root(). If you're doing pivot_root() then you've got initrd, in which case you can create compatibility symlinks from user-space. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [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: [RFC][PATCH] Re: Linux 2.4.4-ac10
On Sun, 20 May 2001, Marcelo Tosatti wrote:
> On Sat, 19 May 2001, Mike Galbraith wrote:
>
> > @@ -1054,7 +1033,7 @@
> > if (!zone->size)
> > continue;
> >
> > - while (zone->free_pages < zone->pages_low) {
> > + while (zone->free_pages < zone->inactive_clean_pages) {
> > struct page * page;
> > page = reclaim_page(zone);
> > if (!page)
>
>
> What you're trying to do with this change ?
Just ensuring that I never had a large supply of cleaned pages laying
around at a time when folks are in distress. It also ensures that you
never donate your last reclaimable pages, but that wasn't the intent.
It was a stray though that happened to produce measurable improvement.
-Mike
-
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: [kbuild-devel] Re: CML2 design philosophy heads-up
On 21 May 2001, Jes Sorensen wrote: > John> Au contraire. It is very reasonable to have both python and > John> python2 installed. Having two different gcc versions installed > John> is a big pain in the arse. > > It's not unreasonable to have both installed, it's unreasonable to > require it. > > Eric seems to think he can tell every distributor to ship Python2 > tomorrow. Well it's a fine dream but it's not going to happen Distributors aren't going to ship Linux 2.5.x tomorrow either. Nicolas - 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] Re: Linux 2.4.4-ac10
On Sun, 20 May 2001, Rik van Riel wrote: > On Sun, 20 May 2001, Mike Galbraith wrote: > > On 20 May 2001, Zlatko Calusic wrote: > > > > Also in all recent kernels, if the machine is swapping, swap cache > > > grows without limits and is hard to recycle, but then again that is > > > a known problem. > > > > This one bugs me. I do not see that and can't understand why. > > Could it be because we never free swap space and never > delete pages from the swap cache ? I sent a query to the list asking if a heavy load cleared it out, but got no replies. I figured about the only thing it could be is that under light load, reclaim isn't needed to cure and shortage. -Mike - 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: Background to the argument about CML2 design philosophy
On 20 May 2001, Robert M. Love wrote: > I feel that there should *never ever* be a legit situation that the > configuration tool does not allow. Not ever. Two reasons: > > First, I tend to trust the config tools (perhaps too much). If they > tell me x implies y, or x implies not y, I will believe it. I won't > think "hm, the code must be wrong, let me hand edit the config" (which > is something I don't want to have to do, anyhow). Then just don't go as far as using it in "Expert (might be unsafe)" mode. If you blindly trust the tool that much the intermediate mode might be what you need. Nicolas - 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: Background to the argument about CML2 design philosophy
On Sun, 20 May 2001, Eric S. Raymond wrote: > In order to prevent that happening, I would like to have some recognized > criterion for configuration cases that are so perverse that it is a > net loss to accept the additional complexity of handling them within the > configurator. Simple: That extreme perversion represent a kernel that wouldn't compile. You can't have NFS support if you didn't select networking support, etc. Such is the recognized basics. Next, you can ask the question if you would have to modify the ruleset to add a new driver to be able to use a feature. Exemple: will you need to write a new driver for a special IDE interface card and add it in the ruleset before you could use IDE cdrom support on the MVME147 SBC? If you have to edit it anyway then it shouldn't be much pain to remove the unconditionnal removal of IDE support for that target. For all other combinations where a slight possibility might make you doubt then the choice should remain at least in expert mode. People might also want to remove support for subsystems on a specific target even if the device comes soldered on it, just because they won't use it anyway and they want to optimize their kernel size for better memory usage. IMHO your design goal now is mainly about finding a way to describe rule derivation related to the selected expertise mode, and only enforce the strictly impossible combinations for expert mode, just like CML1 is doing while removing obvious derivations for novice users. Now you protest with: > That pushes the third button. I'm nervous that if we go down this path > we will end up with a thicket of modes and a combinatorial explosion > in ruleset complexity, leading immediately to a user configuration > experience that is more complex than necessary, and eventually to an > unmaintainable mess in the rulesfiles. Eric: with this I think you know what everybody here is wishing for, and you just perfectly stated your design constraint in achieving it. You can't avoid the "all semi-possible combination allowed" mode. So let's switch to the implementation discussion instead. Nicolas - 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: [RFD w/info-PATCH] device arguments from lookup, partion code
On Mon, 21 May 2001, Ingo Molnar wrote: > > On Sun, 20 May 2001, Alexander Viro wrote: > > > Linus, as much as I'd like to agree with you, you are hopeless > > optimist. 90% of drivers contain code written by stupid gits. > > 90% of drivers contain code written by people who do driver development in > their spare time, with limited resources, most of the time serving as a > learning excercise. And they do this freely and for fun. Accusing them of > being 'stupid gits' is just micharacterising the situation. I would disagree with both of you. The problem is not whether people do it with limited resources or time, or whether they are stupid or not. The problem is that if you expect to get nice code, you have to have nice interfaces and infratructure. And ioctl's aren't it. The reason we _can_ write beautiful filesystems these days is that the VFS layer _supports_ it. In fact, the VFS layer has tons of infrastructure and structure that makes it _hard_ to write bad filesystem code (which is not to say that we don't have ugly code there - but much of it is due to historically not having had quite the same level of infrastructure). If we had nice infrastructure to make ioctl's more palatable, we could probably make do even with the current binary-number interfaces, simply because people would use the infrastructure without ever even _seeing_ how lacking the user-level accesses are. But that absolutely _requires_ that the driver writers should never see the silly "pass a random number and a random argument type" kind of interface with no structure or infrastructure in place. Because right now even _good_ programmers make a mess of the fact that they get passed a bad interface. Think of it this way: the user interface to opening a file is "open()" with pathnames and magic flags. But a filesystem never even _sees_ that interface, it sees a very nicely structured setup where all the argument parsing and locking has already been done for it, and the magic flags don't even exist any more as far as the low-level FS is concerned. Which is why filesystems _can_ be clean. In contrast, ioctl's are passed through directly, with no help to make them clean. 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: [RFD w/info-PATCH] device arguments from lookup, partion code
From: "Alexander Viro" <[EMAIL PROTECTED]> > On Sun, 20 May 2001, Paul Fulghum wrote: > > I'll be the first to admit there is some ugliness in my driver. > > So will anyone here regarding his or her code. Count me in, BTW. > > Could you reread the posting you are refering to? Sorry if I misunderstood. My post was as much in response to several current threads revolving around device major numbers and ioctl calls (I use both!). Many postings seem to imply driver writers must be flawed for using these flawed facilities. Driver writers don't use device major numbers and ioctl calls because they are brain damaged, they use them because they are accepted practice and they work (albeit imperfectly). I have no problem moving to better solutions *as they become available*. But I have seen multiple references to 'causing pain' for people by restricting their use while alternatives (only now being discussed and decided) are years away in the next stable kernel. All I hope for is a reasonable path to get there (better alternatives) from here. My 2 cents, with no intent to offend anyone. Paul Fulghum [EMAIL PROTECTED] Microgate Corporation http://www.microgate.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: Background to the argument about CML2 design philosophy
> derive MVME147_SCSI from MVME147 & SCSI It seems that the preferred semantics would be: default MVME147_SCSI from MVME147 & SCSI That way the platform defines sane defaults, but no flexibility has been taken away. Presumably many of these defaulted options would also be ones that would be configured not to be changeable in novice mode. The novice gets the vanilla platform defaults without being bothered by detailed options, and can switch to expert mode if they need more control. The experts get all the options presented, but also get to benefit from the smart platform defaults. 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: question: permission checking for network filesystem
Mikulas Patocka wrote: >If you are checking permissions on server, read/execute have no security >meaning. This seems a bit too strong. If I try to exec a file that has read permission enabled but not execute permission, I'd like this to fail. You can just imagine sysadmins who turn off exec bits on old buggy apps to prevent users from executing them, who could get bit in the butt by the sort of unexpected behavior that would result from ignoring execute permission bits. - 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.4.5-pre4 drivers/usb/ov511.c
Did not get the word on change to video_register_device added parameter nr something. Garst - 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: const __init
On Mon, May 21, 2001 at 12:19:49AM +0200, Ingo Oeser wrote: > AFAIK "const" is only a promise to the compiler, that we write > this data ONCE and read only after this initial write. So the > decision on the section is implementation defined. No, the problem is not with which section, but what flags that section should have. If you put only "const" data in a section, then the section should have SHF_WRITE clear. Conversely, if you put writable data in a section then SHF_WRITE should be set. Now, one could argue that gcc should scan the entire file to see if there are any non-constant data members added to a particular section, and set SHF_WRITE if any such exist. My answer is: you would not like gcc's memory usage under these conditions. 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: [kbuild-devel] Re: CML2 design philosophy heads-up
On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote:
> On 21 May 2001 02:29:17 +0200, Jes Sorensen wrote:
> > John> Au contraire. It is very reasonable to have both python and
> > John> python2 installed. Having two different gcc versions installed
> > John> is a big pain in the arse.
> >
> > It's not unreasonable to have both installed, it's unreasonable to
> > require it.
> >
> > Eric seems to think he can tell every distributor to ship Python2
> > tomorrow. Well it's a fine dream but it's not going to happen;
>
> I think this is a very important point, and one I agree with. I tend to
> let my distribution handle stuff like python. now, I use RedHat's
> on-going devel, RawHide. it is not using python2. in fact, since
> switching to python2 may break old stuff, I don't expect python2 until
> 8.0. that wont be for 9 months. 90% of RedHat's configuration tools, et
> al, are written in python1 and they just are not going to change on
> someone's whim.
2.6.0 isn't going to happen for at least a year or two. What's the problem ?
Want 2.5.X ? Get the tools too.
I'm in no position to push people around, but I think the whining about CML2
tool requirements is completely unjustified. If we required that everything
worked with GCC 2.7.2 and nmake, where would we be today ? I'm a lot more
worried about CML2 itself than about the tools it requires :)
>
> im not installing python2 from source just so i can run some new config
> utility.
python2 will be in rawhide when 2.5 development requires it, if I'm not much
mistaken.
Whether CML2 requires python2 or not, the distributions will change. This is
not about Eric pushing something down people's throats. Tools evolve, and new
revisions introduce incompatibilities, but distributions still follow the
evolution. Nobody ships perl4 today either.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
-
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/
tulip driver BROKEN in 2.4.5-pre4
Okay, so Jeff Garzik already knows about this - I told him last week - but seeing as how the code has made it to a Linus pre-release without a fix I thought I'd better post the breakage description to l-k! The symptoms are: In 2.4.5-pre4 (and 2.4.4-ac8 and above - note: I didn't try -ac7) system boots up normally, card is recognised etc, but all networking services fail because it's not possible to talk to the network. The system appears to be stable apart from the bug (possible to compile kernels, run X, etc.), but nothing gets to or from the network. I'm using the "DECchip Tulip (dc21x4x) PCI support" option to get the driver for the PCI card which has a Digital 21041 chip in it. FWIW I think it might be related to the selection of full- or half-duplex. 2.4.4-ac6 (which works fine) says: Port selection is half-duplex when I run tulip-diag, whereas 2.4.5-pre4 says Port selection is full-duplex My system is RH7.1 (using gcc-2.96 not kgcc) Duron 750, KT133 chipset (not kt133a!) Network card details (it is a PCI): Kingston KNE40BT (1995) Digital 21041-AA DC1017BA 21-40756-01 Dec 1994 S15313-02 A 9615 More details on request. And I'm willing to test patches... John [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: [kbuild-devel] Re: CML2 design philosophy heads-up
On 21 May 2001 02:29:17 +0200, Jes Sorensen wrote: > John> Au contraire. It is very reasonable to have both python and > John> python2 installed. Having two different gcc versions installed > John> is a big pain in the arse. > > It's not unreasonable to have both installed, it's unreasonable to > require it. > > Eric seems to think he can tell every distributor to ship Python2 > tomorrow. Well it's a fine dream but it's not going to happen; I think this is a very important point, and one I agree with. I tend to let my distribution handle stuff like python. now, I use RedHat's on-going devel, RawHide. it is not using python2. in fact, since switching to python2 may break old stuff, I don't expect python2 until 8.0. that wont be for 9 months. 90% of RedHat's configuration tools, et al, are written in python1 and they just are not going to change on someone's whim. im not installing python2 from source just so i can run some new config utility. (on another note, about the coexist issue: am i going to have a python and python2 binary? so now the config tool will find which to use, ala the kgcc mess? great) -- Robert M. Love [EMAIL PROTECTED] [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: 2.4.4 del_timer_sync oops in schedule_timeout
Ingo Molnar wrote: > > On Sat, 19 May 2001, Jacob Luna Lundberg wrote: > > > This is 2.4.4 with the aic7xxx driver version 6.1.13 dropped in. > > > Unable to handle kernel paging request at virtual address 78626970 > > this appears to be some sort of DMA-corruption or other memory scribble > problem. hexa 78626970 is ASCII "pibx", which shows in the direction of > some sort of disk-related DMA corruption. It could be timer-list corruption. Someone released some memory which had a live timer in it. The memory got recycled and then the timer list traversal fell over it. There was a convincing report of this a few weeks back on a system which didn't have any unusual drivers in it. It was inconclusive. That system was SMP, so it could have been a timer deletion race. This bug is so damn hard to track down that it may be worth putting some special walk-the-timer-lists code inside kfree()+SLAB_POISON. - - 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: [kbuild-devel] Re: CML2 design philosophy heads-up
On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote: > distributions). 18 months is more realistic for it to be deployed > widely enough. People who are going to be savvy enough to install a development 2.5.* kernel that is defining a new configuration utility are going to be savvy enough to install python. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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: alpha iommu fixes
On Sun, May 20, 2001 at 06:03:44PM -0700, David S. Miller wrote: > But for the time being, everyone assumes address zero is not valid and > it shouldn't be too painful to reserve the first page of DMA space > until we fix this issue. Indeed, virtually all PCI systems have legacy PeeCee compatibility crap handing out in low i/o memory, and we don't use the first megabyte or so. 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/
PATCH: ali noautodma, and Alpha AXP
The hardware: UP1000 Alpha, with ALI M1543C IDE. Fujitsu 2GB udma33
drive, I think. ATAPI UDMA CDROM.
The problem: 2.2.15 (as packaged with MDK 7.1 for Alpha) works fine.
2.4.current, both ac tree and linus tree, fail to work at all. I've
tried all combinations I can think of, for: with and without the
alim15xx.c driver, with/out IDEDMA, with/out IDEDMA on auto, with/out
"ide=nodma" on cmdline.
2.2.x gives the message "DMA disabled (BIOS)", and tunes the drives for
PIO.
2.4.x, even with "nodma", tunes the hard drive and CDROM drive for
udma. All hard drive accesses fail with "hda: lost interrupt" and "hdc:
lost interrupt". With the attached patch, it no longer appears to tune
the drives for UDMA, but I still get lost interrupt messages and no
usable drives.
--
Jeff Garzik | "Do you have to make light of everything?!"
Building 1024| "I'm extremely serious about nailing your
MandrakeSoft | step-daughter, but other than that, yes."
Index: linux_2_4/drivers/ide/alim15x3.c
diff -u linux_2_4/drivers/ide/alim15x3.c:1.1.1.49
linux_2_4/drivers/ide/alim15x3.c:1.1.1.49.6.1
--- linux_2_4/drivers/ide/alim15x3.c:1.1.1.49 Thu May 17 10:12:07 2001
+++ linux_2_4/drivers/ide/alim15x3.cSun May 20 16:16:52 2001
@@ -679,19 +679,21 @@
hwif->drives[0].autotune = 1;
hwif->drives[1].autotune = 1;
hwif->speedproc = _tune_chipset;
-#ifndef CONFIG_BLK_DEV_IDEDMA
- hwif->autodma = 0;
- return;
-#endif /* CONFIG_BLK_DEV_IDEDMA */
+#ifdef CONFIG_BLK_DEV_IDEDMA
if ((hwif->dma_base) && (m5229_revision >= 0x20)) {
/*
* M1543C or newer for DMAing
*/
hwif->dmaproc = _dmaproc;
- if (!noautodma)
- hwif->autodma = 1;
+ hwif->autodma = 1;
}
+
+ if (noautodma)
+ hwif->autodma = 0;
+#else
+ hwif->autodma = 0;
+#endif /* CONFIG_BLK_DEV_IDEDMA */
}
void __init ide_dmacapable_ali15x3 (ide_hwif_t *hwif, unsigned long dmabase)
Re: alpha iommu fixes
On Sun, May 20, 2001 at 06:01:40PM -0700, David S. Miller wrote: > > Andrea Arcangeli writes: > > > Well this is news to me. No drivers understand this. > > > > Yes, almost all drivers are buggy. > > No, the interface says that the DMA routines may not return failure. The alpha returns a faliure since day zero of iommu support, the sparc64 has too otherwise it's even more buggy than alpha when the machine runs out of pci virtual address space. > If you want to change the DMA api to act some other way, then fine > please propose it, but do not act as if today they have to act this > way because that is simply not true. About the pci_map_single API I'd like if bus address 0 would not be the indication of faluire, mainly on platforms without an iommu that's not nice, x86 happens to get it right only because the physical page zero is reserved for completly other reasons. so we either add a err parameter to the pci_map_single, or we define a per-arch bus address to indicate an error, either ways are ok from my part. Andrea - 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: alpha iommu fixes
On Sun, May 20, 2001 at 06:07:17PM -0700, David S. Miller wrote: > > Andrea Arcangeli writes: > > > [..] Even sparc64's fancy > > > iommu-based pci_map_single() always succeeds. > > > > Whatever sparc64 does to hide the driver bugs you can break it if you > > pci_map 4G+1 bytes of phyical memory. > > Which is an utterly stupid thing to do. > > Please construct a plausable situation where this would occur legally > and not be a driver bug, given the maximum number of PCI busses and > slots found on sparc64 and the maximum _concurrent_ usage of PCI dma > space for any given driver (which isn't doing something stupid). Assume I have a dozen of PCI cards that does DMA using SG tables that can map up to some houndred mbytes of ram each, so I can just program the cards to start the dma on those houndred mbyte of ram, most of the time the I/O is not simulaneous, but very rarely it happens to be simultaneous and in turn it tries to pci_map_sg more than 4G of physical ram. After that sparc64 iommu code will say "bye bye" and the machine will crash because the nic driver is not checking for pci_map_single faliures. I don't see why the above scenario should be classified as stupid. such pci_map_* API and the device drivers have to be generic. It's like if you say me that there's no need to check for alloc_pages(GFP_ATOMIC) faliures in the device drivers because all machines you are using have 256G of ram and you never use all the physical ram with your workloads. I would never buy such an argument. Furthmore currently (2.4.5pre3) on alpha you only need to ask the iommu to map more than 128mbyte of ram to crash (I increased it to 512mbyte at least, Jay said my first patch that increased it to 1G is risky because some device gets confused by bus addresses at around -1M and we keep the dynamic window above 3G, 512M should still be enough to cover 99% of hardware configurations I agree on that but this is not a good excuse to left all device drivers buggy just because those bugs doesn't trigger in all the hardware configurations out there). Andrea - 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] ppc xconfig 2.2.5-pre4
Hi, The following patch fixes ppc xconfig potential problem introduced in 2.4.5-pre4. Andrzej *** diff -uNr linux-2.4.5-pre4/arch/ppc/config.in linux-pre4/arch/ppc/config.in --- linux-2.4.5-pre4/arch/ppc/config.in Mon May 21 03:17:02 2001 +++ linux-pre4/arch/ppc/config.in Mon May 21 03:22:51 2001 @@ -135,7 +135,8 @@ define_bool CONFIG_PCI $CONFIG_PCI_QSPAN else if [ "$CONFIG_APUS" = "y" ]; then - bool 'PCI for Permedia2' CONFIG_PCI + bool 'PCI for Permedia2' CONFIG_PCI_PERMEDIA + define_bool CONFIG_PCI $CONFIG_PCI_PERMEDIA else define_bool CONFIG_PCI y fi -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] phone (48)(58) 347 14 61 Faculty of Applied Phys. & Math., Technical University of Gdansk - 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: Background to the argument about CML2 design philosophy
David Woodhouse <[EMAIL PROTECTED]>: > Let's not talk about CONFIG_AUNT_TILLIE any more, or change the existing > behaviour of config options to make that the default, until we've settled > the discussion about CML2. What discussion is that? Unless Linus has changed his mind and I don't know about it, CML2 is going in between 2.5.1 and 2.5.2. The engine is working. Why is it not yet time to discuss ruleset design and modes? -- http://www.tuxedo.org/~esr/;>Eric S. Raymond That the said Constitution shall never be construed to authorize Congress to infringe the just liberty of the press or the rights of conscience; or to prevent the people of the United states who are peaceable citizens from keeping their own arms... -- Samuel Adams, in "Phila. Independent Gazetteer", August 20, 1789 - 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: alpha iommu fixes
Andrea Arcangeli writes: > > [..] Even sparc64's fancy > > iommu-based pci_map_single() always succeeds. > > Whatever sparc64 does to hide the driver bugs you can break it if you > pci_map 4G+1 bytes of phyical memory. Which is an utterly stupid thing to do. Please construct a plausable situation where this would occur legally and not be a driver bug, given the maximum number of PCI busses and slots found on sparc64 and the maximum _concurrent_ usage of PCI dma space for any given driver (which isn't doing something stupid). Later, David S. Miller [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: Problems with buslogic and osst driver
Em Sun, May 20, 2001 at 08:46:44PM +0100, Alan Cox escreveu: > > So I have 2 questions: > > 1) Does anyone know if Leonard Zubkoff is still around? > > Leonard was around at OLS last year and working at VA. Its possible he was > laid off but I've heard nothing to suggest that so he's probably just busy > or on holiday I've met him at the 2.5 kernel summit in CA +- one month ago and he is still maintaining at least the DAC960 driver, not sure about the buslogic > > 2) Is anyone else looking after the BusLogic driver these days? > > Not afaik but feel free to pitch in yes, we need more people fixing drivers, thats for sure - Arnaldo - 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: alpha iommu fixes
Andrea Arcangeli writes: > > Well this is news to me. No drivers understand this. > > Yes, almost all drivers are buggy. No, the interface says that the DMA routines may not return failure. If you want to change the DMA api to act some other way, then fine please propose it, but do not act as if today they have to act this way because that is simply not true. Later, David S. Miller [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: const __init
On Sun, 20 May 2001 22:16:11 +0200, Franz Sirl <[EMAIL PROTECTED]> wrote: >Yes, and gcc3 errors on these constructs, cause it cannot decide if the data >should be put into a .data or .rodata section. >Dunno if it's worth to create a __initconstdata/__initrodata though, but it >would be easy implement I guess. Not worth it. Adding finer grained init.data sections requires changes to every architecture's vmlinux.lds script but it gains you nothing, the sections are discarded after the kernel has booted. - 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: Background to the argument about CML2 design philosophy
> "Eric" == Eric S Raymond <[EMAIL PROTECTED]> writes: Eric> The first candidates I found were questions associated with Eric> built-in SCSI and Ethernet on Macintoshes, on the Sun 3 and Eric> Sun3x, and with built-in facilities on the MVME147 single-board Eric> computer. So I wrote derivations that looked like this: [snip derive rules] Eric> # These were separate questions in CML1 derive MAC_SCC from MAC Eric> & SERIAL derive MAC_SCSI from MAC & SCSI derive SUN3_SCSI from Eric> (SUN3 | SUN3X) & SCSI Eric> By doing this I killed two birds with one stone -- got rid of Eric> some holes in Configure.help and (more importantly) moved the Eric> configuration experience away from low-level, hardware-oriented Eric> questions towards where I think it ought to be. That is, you Eric> specify a platform and the services you want and the ruleset Eric> computes the low-level facilities to be linked in. And you suddenly imposed decisions on people. Wether or not you are an expert it is reasonable to expect that you want to use modules just as it is just as reasonable to expect that you do not. In some cases you want your Ethernet as a module in some case you want the low level SCSI driver but not the SCSI mid layer. Eric> After some back-and-forthing about the technical facts, several Eric> things emerged: Eric> 1. The Mac derivations were half-right. The MAC_SCC one is good Eric> but Macs can have either of two different SCSI controllers. I Eric> fixed that with help from Ray Knight, who maintains the 68K Mac Eric> port. Eric> 2. Nobody had a problem with the SUN3_SCSI derivation. Did you ever get an ACK on it or no answer? Eric> 3. The MVME derivations are correct *if* (and only if) you agree Eric> to ignore the possibility that somebody could want to ignore the Eric> onboard hardware, plug outboard disk or Ethernet cards into the Eric> VME-bus connector, and do something like running SCSI-over-ATAPI Eric> to the outboard device. (I missed these possibilities when I Eric> wrote the derivations.) Or wants to use modules. And yes Aunt Tillie might want to do so, if the person who sold her her Linux CD provided a bunch of scripts for packing up things in a specific way. Eric> The MVME situation is an almost perfect test case, because while Eric> breaking the assumption behind that derivation is physically Eric> possible it would be a rather perverse thing to do. The VME147 Eric> is an old design, dating from 1988; it's long since been Eric> superseded by MPCxxx SBCs based on the PowerPC that have a Eric> better processor, lower power consumption, and more on-board Eric> peripheral hardware. IDE/ATAPI didn't exist during most of its Eric> design lifetime, and the only way anyone is ever going to hook Eric> an outboard device to one of these puppies again is if some Eric> hacker pulls a dusty one off a shelf for some garage project. Bt wrong. The MVME cards are still heavily used in control systems and similar places. It's the only place where m68k usage is not dying for real. Eric> So far, I have to say I'm disappointed in the quality of the Eric> debate. Almoist nobody seems to want to think about this Eric> tradeoff globally, as a systems design issue. Instead, I'm Eric> hearing a lot of reflexive chuntering that we have to do things Eric> a certain way because we've always done them a certain way, and Eric> who am I to even dare *think* about raising different Eric> possibilities? So far the introduction of CML2 has been overly disppointing, from day one it's been 'I have this great idea and since I think it's great, you obviously have to think so as well'. Now I take it the derived rules are still only enforced under the 'novice' option, though you haven't exactly made that clear in the discussion (nor did you do so when you initially brought it up). Jes - 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: alpha iommu fixes
On Sun, May 20, 2001 at 04:05:18PM +0400, Ivan Kokshaysky wrote: > Ok. What do you think about reorg like this: > basically leave the old code as is, and add > if (is_pyxis) > alpha_mv.mv_pci_tbi = cia_pci_tbi_try2; > else > tbia test > ... Seems good. > 21174 docs confirm that (though in a very low voice ;-) : > "The 21174 may hang with TBIA=3." Mmm. Tasty. :-) 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: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, 20 May 2001, Paul Fulghum wrote: > I'll be the first to admit there is some ugliness in my driver. So will anyone here regarding his or her code. Count me in, BTW. Could you reread the posting you are refering to? - 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: [RFD w/info-PATCH] device arguments from lookup, partion code
On Mon, 21 May 2001, Ingo Molnar wrote: > > On Sun, 20 May 2001, Alexander Viro wrote: > > > Linus, as much as I'd like to agree with you, you are hopeless > > optimist. 90% of drivers contain code written by stupid gits. > > 90% of drivers contain code written by people who do driver development in > their spare time, with limited resources, most of the time serving as a > learning excercise. And they do this freely and for fun. Accusing them of Probably 100% of drivers contains code from more than one author. > being 'stupid gits' is just micharacterising the situation. People do not > get born as VFS hackers, there is a very steep learning curve, and only a > few make it to to have knowledge like you. Much of the learning curve of > various people has traces in drivers/*, it's more like the history of > Linux then some coherent image of people's capabilities. Grrr... Ingo, could you read what I said? I'm not talking about problems coming from lack of knowledge about the kernel. I'm not saying that authors of drivers are stupid gits (in the cases when they in all probability are such they are usually anonymous - FUBAR Acme Inc. is all you see). I'm not saying that 90% of code in drivers is crap. What I am saying is that in a lot of drivers you can find a code that is result of plain and simple lack of knowledge about basics of C. And I mean the basics, not the nontrivial parts. "Oh, look, I don't know C, here's that project, let's write something and submit the patch" looks pretty stupid to me. I'm not talking about bugs. I'm not talking about stupid interfaces. I'm not talking about typos. I'm not talking about people doing strlen() on arrays that came from unverified source. I'm talking about the code that was obviously written by somebody who considers C as voodoo. The things Linus refered to pale on that background. On the bogosity scale we have a lot of code that is way higher. Since it manages to stay unnoticed for years... And no, I don't think that it's an arrogance. BTW, I don't know who the authors of these pieces are. I know that problems they had could be cured by reading any book on C (K, Bolsky, whatever) and considering how long some of that stuff had been in the tree... Well, doesn't speak highly of the intellect of those who'd written 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: [kbuild-devel] Re: CML2 design philosophy heads-up
> "John" == John Cowan <[EMAIL PROTECTED]> writes: John> Jes Sorensen wrote: >> Telling them to install an updated gcc for kernel compilation is a >> necessary evil, which can easily be done without disturbing the >> rest of the system. Updating the system's python installation is >> not a reasonable request. John> Au contraire. It is very reasonable to have both python and John> python2 installed. Having two different gcc versions installed John> is a big pain in the arse. It's not unreasonable to have both installed, it's unreasonable to require it. Eric seems to think he can tell every distributor to ship Python2 tomorrow. Well it's a fine dream but it's not going to happen; Most distributors do not ship new major versions of tools in their minor number release versions. I've seen him mention the number 6 months until everybody ships it, but a) thats not going to happen Red Hat is currently at 7.1 (if one looks at their release history, one would say there is a good chance there will be a 7.2) not to mention the release rate of Debian (not sure about the current state of all other distributions). 18 months is more realistic for it to be deployed widely enough. >> So far I haven't heard a single developer say something positive >> about CML2, the most positive I have heard so far has been >> "whatever", "it's his choice", "I don't care", "I want to >> hack". The majority are of the "NO!" and "you got to be kiddin'". John> Anonymized hearsay evidence is less than convincing. Well I don't like to quote personal conversations without peoples' approval, now both David Woodhouse and Arjan are two examples. Jes - 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: [RFD w/info-PATCH] device arguments from lookup, partion code
>> 90% of drivers contain code written by stupid gits. > > From: "Alan Cox" > I think thats a very arrogant and very mistaken view of the problem. 90% > of the driver are written by people who are > > - Copying from other drivers > - Using the existing API's to make their job easy > - Working to timescales > - Just want it to work I'll be the first to admit there is some ugliness in my driver. Some originates from accepted methods when the driver originated. (points 1 and 2 above) Some comes from doing new things with only the existing infrastructure, because changing the infrastructure is deemed too intrusive. (points 3 and 4 above) Stable infrastructure is good, but sometimes ugliness results. Some is the result of genuine mistakes (people who have written nothing but perfect code flame away). I fix these as they are found through use and review, and the code improves. (I *really do* want my driver to work!) As new facilities and guidelines are made available, I *gladly* and *gratefully* use them, and the code improves. Calling driver writers stupid and devising punitive measures to 'cause them pain' seems less useful. Paul Fulghum [EMAIL PROTECTED] Microgate Corporation http://www.microgate.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: [kbuild-devel] Patch for sbus makefile bug
On Sun, 20 May 2001 11:47:38 -0400, "Eric S. Raymond" <[EMAIL PROTECTED]> wrote: >Somebody failed to track a module name change. >-obj-$(CONFIG_BBC_I2C) += bbc.o >+obj-$(CONFIG_BBC_I2C) += bbc_i2c.o bbc-objs := bbc_i2c.o bbc_envctrl.o The module is bbc.o, bbc_i2c.o is a sub-object of bbc.o, the selection is correct (2.4.5-pre4). - 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: add page argument to copy/clear_user_page
Linus Torvalds writes:
> If you add the page argument, why leave the old arguments lingering there
> at all? They only create confusion, and add no information.
You mean the `to' pointer argument, or the `vaddr' argument? The
`vaddr' argument isn't redundant, it's the user virtual address where
the page is mapped, and sparc64 needs it in order to avoid D-cache
aliasing issues I believe. (Dave?)
As for the `to' argument, yes it is redundant since it is just kmap(page).
But copy/clear_user_page isn't the interface that gets called from the
MM stuff, copy/clear_user_highpage is, defined in include/linux/highmem.h.
These are two of a whole series of functions which all do kmap, do
something, kunmap.
IMHO having the kmap/kunmap calls in copy/clear_user_highpage in
include/linux/highmem.h is the best approach because it means that
most architectures can just #define copy/clear_user_page as
copy/clear_page in include/asm/page.h (as they do at the moment). It
means that the kmap/kunmap calls are in one place only instead of
being duplicated in every architecture.
But we could instead push the kmap/kunmap down into copy/clear_user_page.
Then we might as well rename them into copy/clear_user_highpage. Here
is how it might turn out in include/asm-i386/page.h (and asm-alpha,
asm-arm, asm-crus, asm-s390, asm-sh, asm-s390x...):
extern void clear_page(void *page);
extern void copy_page(void * _to, void * _from);
#define clear_user_highpage(page, vaddr)\
do {\
struct page *__page = page; \
clear_page(kmap(__page)); \
kunmap(__page); \
} while (0)
#define copy_user_highpage(to, from, vaddr) \
do {\
struct page *__to = to, *__from = from; \
copy_page(kmap(__to), kmap(__from));\
kunmap(__from); \
kunmap(__to); \
} while (0)
Doing it with inline functions would be cleaner but would mean that we
would need the declaration of kmap/kunmap in page.h. That would mean
that we would need to #include in include/asm/page.h
which is starting to get pretty messy and inviting circular
inclusions. We could move these declarations to another file in
include/asm - include/asm/highmem.h might seem the natural place but
it is only used if CONFIG_HIGHMEM is defined and not all ports have
it.
I assume nobody wants to do these functions out-of-line. :)
So on the whole the way I had it seems cleanest to me. But I can whip
up a patch to do the kmap/kunmap in the architecture-specific files
instead, if you prefer - if so, do you prefer the macro version or the
inline function version?
Paul.
-
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: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, 20 May 2001, Alexander Viro wrote: > Linus, as much as I'd like to agree with you, you are hopeless > optimist. 90% of drivers contain code written by stupid gits. 90% of drivers contain code written by people who do driver development in their spare time, with limited resources, most of the time serving as a learning excercise. And they do this freely and for fun. Accusing them of being 'stupid gits' is just micharacterising the situation. People do not get born as VFS hackers, there is a very steep learning curve, and only a few make it to to have knowledge like you. Much of the learning curve of various people has traces in drivers/*, it's more like the history of Linux then some coherent image of people's capabilities. Ingo - 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: sqrt in kernel?
On Mon, 21 May 2001, Matti Aarnio wrote: > In some cases even the fast-paths carry FP/MMX code, > but those are cases where the save/restore overhead > becomes negligible for all of the other processing > that is going on. even in that case you must make sure you dont raise any FP exceptions, which could change the non-CPU based FPU context of the process. Ingo - 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/
Proxim Symphony wireless drivers
Hi, I am using Proxim Symphony Wireless LAN card on one of my systems with kernel 2.2.19. I may reinstall with a different Linux distro and upgrade to kernel 2.4. The Proxim Symphony Wireless LAN site (http://www.komacke.com) has disappeared. Does anyone know where I can find drivers for Linux for this product? TIA. -- Subba Rao [EMAIL PROTECTED] http://members.home.net/subba9/ GPG public key ID 27FC9217 - 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: Background to the argument about CML2 design philosophy
[EMAIL PROTECTED] said: > Maybe it would be possible to separate "hard" dependencies like the > current system has with the "soft" ones one needs for entry-level > configtools. Actually, the current system has both types. As well as the "hard" dependencies, we also have stuff like CONFIG_PARTITION_ADVANCED, CONFIG_CPU_ADVANCED, CONFIG_FBCON_ADVANCED, CONFIG_MTD_DOCPROBE_ADVANCED, etc. CONFIG_EXPERIMENTAL serves a very similar purpose, too. These things have already been set up in the way that developers prefer it. CML2 allows us to be more flexible than we were before, and that can be a good thing when used in moderation. But please, for the sake of the sanity of all concerned, do things one at a time. Provide for merging into 2.5 a set of rules which reproduce the existing CML1 behaviour in this respect. Eric, if you want to make further changes later to introduce new 'modes' for kernel configuration, that's an entirely separate issue. Please don't confuse the issue by trying to do it at the same time as introducing CML2. CONFIG_AUNT_TILLIE does not require CML2. CML2 does not require CONFIG_AUNT_TILLIE. Let's not talk about CONFIG_AUNT_TILLIE any more, or change the existing behaviour of config options to make that the default, until we've settled the discussion about CML2. -- dwmw2 - 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: question: permission checking for network filesystem
Hi > I'm trying to impelemnt a lightweight network filesystem and ran into > trouble implementing lookup, permissions and open. > > The protocol requires me to specify open mode in it's open command. The > open mode has 4 bits: read, write, append and execute. But I can't tell > execution from read in file_operations->open. I could send the open command > from the inode_operations->permission, but this does not solve the problem, > as I can't find weather to count the new file descriptor as reader or > executer (I have to know that when closing the file). The idea of opening files for read and opening files for execution is bogus and you should fix the protocol, not add more crap to your implementation. There are two ways how you can implement security in network file system: 1. you expect that users have not root access on the client machine and you check permissions on client (like in NFS). In this case the 'x' and 'r' bits are checked on the client and you don't have to care about them in protocol. 2. you expect that users have root access on client machine and you check permissions on the server. In this case users can read executed files anyway. > The server always checks permission on the actual request, so I can't open > the file for reading, when it should be open for execution. It seems that you are implementing case 2 of the above. If you are checking permissions on server, read/execute have no security meaning. Client can send 'execute' request and then store data somwhere to file. Opening for 'execute' won't enhance your security. > Could anyone see a solution other than adding a flags to open mode (say > O_EXEC and O_EXEC_LIB), that would be added to the dentry_open in open_exec > and sys_uselib? I don't like the idea of pathing vfs for this. Send always 'open for read' and ignore 'open for execute'. And also remember that having file without read permission and with execute permission makes sence only for suid programs. User can read the file via /proc//mem or attach debugger to the process... Mikulas - 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: waitqueue problem on 2.4.3
I can't see anything immediately wrong with your code - make sure you're compiling against the source for the kernel you're running, with the same options enabled. In general, though, you shouldn't be using any of the sleep_on() functions if you care about the fact that you'll miss wakeup events. -- dwmw2 - 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: [LV] start_thread question...
Okay I think I've gotten it solved most of the way, we weren't calling execve via the system call interface, so once I made it go via the system call and I fill out pc, sp and psl registers in start_thread, it seems to go further.. Thanks for all the help... Dave. On Sun, 20 May 2001, Kenn Humborg wrote: > On Sun, May 20, 2001 at 05:24:48PM +0100, Dave Airlie wrote: > > > > I'm implementing start_thread for the VAX port and am wondering does > > start_thread have to return to load_elf_binary? I'm working on the init > > thread and what is happening is it is returning the whole way back to the > > execve caller .. which I know shouldn't happen. > > > > so I suppose what I'm looking for is the point where the user space code > > gets control... is it when the registers are set in the start_thread? if > > so how does start_thread return > > > > On the VAX we have to call a return from interrupt to get to user space > > and I'm trying to figure out where this should happen... > > I haven't got time to look at this in detail, but you could > probably do it by frobbing the saved registers that will be > restored by the ret_from_syscall in entry.S. Do you have > a pt_regs *regs function argument at the right point? If > so, it should point to these saved registers. > > Later, > Kenn > > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DecStation / Linux VAX / ILUG person - 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] Re: Linux 2.4.4-ac10
On Sat, 19 May 2001, Mike Galbraith wrote:
> @@ -1054,7 +1033,7 @@
> if (!zone->size)
> continue;
>
> - while (zone->free_pages < zone->pages_low) {
> + while (zone->free_pages < zone->inactive_clean_pages) {
> struct page * page;
> page = reclaim_page(zone);
> if (!page)
What you're trying to do with this change ?
-
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: const __init
On Sun, May 20, 2001 at 05:34:48PM -0400, Jeff Garzik wrote: > This might be a very valid point... > > (let me know if the following test is flawed) It is imho. > > [jgarzik@rum tmp]$ cat > sectest.c > > #include > > #include > > static const char version[] __initdata = "foo"; static char version2[] __initdata = "bar"; > > [jgarzik@rum tmp]$ gcc -D__KERNEL__ -I/spare/cvs/linux_2_4/include -Wall >-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe >-mpreferred-stack-boundary=2 -march=i686-c -o sectest.o sectest.c > > [jgarzik@rum tmp]$ > > No section type conflict appears. Now it SHOULD conflict on these binutils, but doesn't on mine (2.9.5) ;-) It is decided to put it into .data.init as expected. AFAIK "const" is only a promise to the compiler, that we write this data ONCE and read only after this initial write. So the decision on the section is implementation defined. What I don't understand is, why GCC overrides our explicit override (done by setting the "section attribute" explicitly). I would consider this a BUG in GCC. I don't understand, why we support this BUG... Maybe some GCC people can enlighten me, why GCC ignores such overrides, that are for the cases where we DO KNOW BETTER than GCC, what section is correct. Regards Ingo Oeser -- To the systems programmer, users and applications serve only to provide a test load. - 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: [LV] start_thread question...
On Sun, May 20, 2001 at 05:24:48PM +0100, Dave Airlie wrote: > > I'm implementing start_thread for the VAX port and am wondering does > start_thread have to return to load_elf_binary? I'm working on the init > thread and what is happening is it is returning the whole way back to the > execve caller .. which I know shouldn't happen. > > so I suppose what I'm looking for is the point where the user space code > gets control... is it when the registers are set in the start_thread? if > so how does start_thread return > > On the VAX we have to call a return from interrupt to get to user space > and I'm trying to figure out where this should happen... I haven't got time to look at this in detail, but you could probably do it by frobbing the saved registers that will be restored by the ret_from_syscall in entry.S. Do you have a pt_regs *regs function argument at the right point? If so, it should point to these saved registers. Later, Kenn - 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: const __init
On Sun, May 20, 2001 at 09:51:04PM +0200, Geert Uytterhoeven wrote: > Appendix: here's the list of affected source files: > > arch/arm/kernel/setup.c Thanks for pointing it out. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - 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/
[OT] util-linux-2.11c released
After man-pages-1.36 and kbd-1.06 today util-linux-2.11c. - 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: const __init
Geert Uytterhoeven wrote: > > On Sun, 20 May 2001, Jeff Garzik wrote: > > Geert Uytterhoeven wrote: > > > Since a while include/linux/init.h contains the line > > > > > > * Also note, that this data cannot be "const". > > > > > > Why is this? Because const data will be put in a different section? > > > > Causes a "section type conflict" build error, at least on x86. > > On m68k I only saw section type conflict errors when using __init while it > should have been __initdata. This might be a very valid point... (let me know if the following test is flawed) > [jgarzik@rum tmp]$ cat > sectest.c > #include > #include > static const char version[] __initdata = "foo"; > [jgarzik@rum tmp]$ gcc -D__KERNEL__ -I/spare/cvs/linux_2_4/include -Wall >-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe >-mpreferred-stack-boundary=2 -march=i686-c -o sectest.o sectest.c > [jgarzik@rum tmp]$ No section type conflict appears. -- Jeff Garzik | "Do you have to make light of everything?!" Building 1024| "I'm extremely serious about nailing your MandrakeSoft | step-daughter, but other than that, yes." - 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] Re: Linux 2.4.4-ac10
On Sun, 20 May 2001, Mike Galbraith wrote: > On 20 May 2001, Zlatko Calusic wrote: > > Also in all recent kernels, if the machine is swapping, swap cache > > grows without limits and is hard to recycle, but then again that is > > a known problem. > > This one bugs me. I do not see that and can't understand why. Could it be because we never free swap space and never delete pages from the swap cache ? Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - 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: sqrt in kernel?
On 20 May 2001, Robert M. Love wrote: > hi, > > is there a sqrt function in the kernel? no. read the FAQ. > i tried finding/grepping around, and found some various arch-specific > stuff for fpu emulation... is there a general sqrt function? is there a In general questions like this are better asked on the kernelnewbies list. Read the FAQ. john - 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: sqrt in kernel?
On Sun, May 20, 2001 at 04:33:20PM -0400, Robert M. Love wrote: > hi, > > is there a sqrt function in the kernel? any other math functions? No. (Assuming FP math sqrt function is your interest.) If you do scaled integers (fractions, with 2^n denominator), you can do newton iteration for sqrt nicely. > i tried finding/grepping around, and found some various arch-specific > stuff for fpu emulation... is there a general sqrt function? is there a > single file to look through with the various math functions? Yes. Userspace. ( ) As a rule: NO FP MATH IS ALLOWED IN THE KERNEL! Now the question: Why do you think you need FP math ? If your case is non-fast-path, you may do complete state save before, and restore after your FP code. In some cases even the fast-paths carry FP/MMX code, but those are cases where the save/restore overhead becomes negligible for all of the other processing that is going on. > thanks, > -- > Robert M. Love > [EMAIL PROTECTED] > [EMAIL PROTECTED] /Matti Aarnio - 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: Background to the argument about CML2 design philosophy
On 20 May 2001 16:47:00 -0400, Eric S. Raymond wrote: > In order to prevent that happening, I would like to have some recognized > criterion for configuration cases that are so perverse that it is a > net loss to accept the additional complexity of handling them within the > configurator. > > A lot of people (including, apparently, you) are saying there are no such > cases. I wonder if you'll change your minds when you have to handle the > overhead yourselves? I feel that there should *never ever* be a legit situation that the configuration tool does not allow. Not ever. Two reasons: First, I tend to trust the config tools (perhaps too much). If they tell me x implies y, or x implies not y, I will believe it. I won't think "hm, the code must be wrong, let me hand edit the config" (which is something I don't want to have to do, anyhow). Second, I like having a lean kernel. Here is an example (I realize this probably won't ever manifest into a real rule): INTEL_I815 implies INTEL_RNG, DRM_I810, INTEL_AGP, I810_TCO, PCI, etc etc. -- I don't want the RNG or TCO watchdog. I don't use the on-board graphics. Nor, if my i815 model supported it, the sound. There are people who want to customize their kernel (hell, everyone at this level of the game). There are people, like David, who have custom setups. We need to support this, without hacking the config (especially if I have to rehack it after every make oldconfig!). I like your design to abstract away low levels features to a more general design. This makes it easier for the novice, and more intuitive for everyone. But not at the expense of limiting possible cases. -- Robert M. Love [EMAIL PROTECTED] [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: [RFC][PATCH] Re: Linux 2.4.4-ac10
On Sun, 20 May 2001, Mike Galbraith wrote: > > Also in all recent kernels, if the machine is swapping, swap cache > > grows without limits and is hard to recycle, but then again that is > > a known problem. > > This one bugs me. I do not see that and can't understand why. To throw away dirty and dead swapcache (its done at swap writepage()) pages page_launder() has to run into its second loop (launder_loop = 1) (meaning that a lot of clean cache has been thrown out already). We can "short circuit" this dead swapcache pages by cleaning them in the first page_launder() loop. Take a look at the writepage() patch I sent to Linus a few days ago. - 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: Background to the argument about CML2 design philosophy
On Sun, May 20, 2001 at 04:47:00PM -0400, Eric S. Raymond wrote: > In order to prevent that happening, I would like to have some recognized > criterion for configuration cases that are so perverse that it is a > net loss to accept the additional complexity of handling them within the > configurator. "It doesn't compile/link" would be a good one. "It requires subsystem FOO to operate" is another (think about IDE DMA drivers and the IDE subsystem, or NIC drivers vs CONFIG_NET) > A lot of people (including, apparently, you) are saying there are no such > cases. I wonder if you'll change your minds when you have to handle the > overhead yourselves? Somehow the current overhead isn't that high. You might argue that the current Config.in is broken given my definition. That is fixable with a day of work; I've been doing so on a regular basis with the tooling I wrote for automatic testing of this. Maybe it would be possible to separate "hard" dependencies like the current system has with the "soft" ones one needs for entry-level configtools. Or maybe it needs 2 files for that.. CML1 style (style, maybe not syntax) ones and the newstyle info. I liked the suggestion where the "automatic" derivations got turned into manual ones for expert mode... I haven't tried CML2 yet (I've yet to find a suitable .deb of Python2 for my Debian Potato playbox) so I don't know if that is actually possible, or that it requires some redesign. Greetings, Arjan van de Ven - 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: Background to the argument about CML2 design philosophy
[EMAIL PROTECTED] said: > I'm nervous that if we go down this path we will end up with a > thicket of modes and a combinatorial explosion in ruleset complexity, > leading immediately to a user configuration experience that is more > complex than necessary, and eventually to an unmaintainable mess in > the rulesfiles. Having too many such modes would be a horrible mess, I agree. > In order to prevent that happening, I would like to have some > recognized criterion for configuration cases that are so perverse that > it is a net loss to accept the additional complexity of handling them > within the configurator. > A lot of people (including, apparently, you) are saying there are no > such cases. I wonder if you'll change your minds when you have to > handle the overhead yourselves? Of course there are such cases. The criterion is that the code does not compile or if it did, it could never be expected to work - like SCSI drivers without SCSI generic, or PCI devices without CONFIG_PCI. This is the major criterion which has defined the dependencies already in the config files. You want to add a new mode which hides some of the more esoteric options. That's fine. So do so, and then we have two modes. It's still not an unmaintainable mess. If having even two modes is going to be too troublesome, then keep the one we have. You can try to simplify it later by encouraging individual maintainers to hide stuff behind CONFIG_*_ADVANCED options. But keep that strictly separate from the CML2 discussion. -- dwmw2 - 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: tcp_mem problem
> the system with problem is using kernel 2.4.2 on an P200 with 64mb ram. It > has about 20 users that use the box... (ftp, telnet, lynx, bitchx,...). > > the problem is when the parameter tcp_mem HIGH gets exeded after about a day > of use! Then the box is going from the net and its not awailable. I tried to > tune the system with adding more in proc tcp_mem but the problem is still > there the box only lasts for bout 2h longer. > > and i get this in messages > > kernel: TCP: too many of orphaned sockets > > It looks like my system is not droping closed sockets? On Sunday 20 May 2001 22:26, you wrote: > > You can check by using netstat -tan > Normally the message is harmless; when it happens the closed sockets are > RST instead of being closed properly. > > > -Andi But why is the server going down when that message apheres in the log?... No one can telnet to the computer, ssh, web is not awailabe... And the message gets repeted all the time. The only thing to do is to reset the server. Well I dont know what else to do. netstat -tan doesnt show anything wrong. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Background to the argument about CML2 design philosophy
David Woodhouse <[EMAIL PROTECTED]>: > I think you already have the mechanism required to answer this - in NOVICE > mode you disallow the strange choices, in EXPERT mode you allow them. That pushes the third button. I'm nervous that if we go down this path we will end up with a thicket of modes and a combinatorial explosion in ruleset complexity, leading immediately to a user configuration experience that is more complex than necessary, and eventually to an unmaintainable mess in the rulesfiles. In order to prevent that happening, I would like to have some recognized criterion for configuration cases that are so perverse that it is a net loss to accept the additional complexity of handling them within the configurator. A lot of people (including, apparently, you) are saying there are no such cases. I wonder if you'll change your minds when you have to handle the overhead yourselves? Sigh... -- http://www.tuxedo.org/~esr/;>Eric S. Raymond "Government is not reason, it is not eloquence, it is force; like fire, a troublesome servant and a fearful master. Never for a moment should it be left to irresponsible action." -- George Washington, in a speech of January 7, 1790 - 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: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, 20 May 2001, Alan Cox wrote: > > Linus, as much as I'd like to agree with you, you are hopeless optimist. > > 90% of drivers contain code written by stupid gits. ^^^ > > I think thats a very arrogant and very mistaken view of the problem. 90% > of the driver are written by people who are written by != contain code written by. Stuff initally written by sane people tends to get all sorts of crap into it. Unfortunately. The problem being: very few people actually read the code in drivers/*. And crap accumulates. The messier it is, the faster it gets shitted. So relying on the people finding crappy ->write() instances and ridiculing the authors in public is... well, somewhat naive. There's more than enough crap already and that simply doesn't happen. It _can_ be done, but it will take more than just having the code sitting there. - 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/
sqrt in kernel?
hi, is there a sqrt function in the kernel? any other math functions? i tried finding/grepping around, and found some various arch-specific stuff for fpu emulation... is there a general sqrt function? is there a single file to look through with the various math functions? thanks, -- Robert M. Love [EMAIL PROTECTED] [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: tcp_mem problem
On Sun, May 20, 2001 at 07:33:15PM +0200, David Osojnik wrote: > the system with problem is using kernel 2.4.2 on an P200 with 64mb ram. It > has about 20 users that use the box... (ftp, telnet, lynx, bitchx,...). > > the problem is when the parameter tcp_mem HIGH gets exeded after about a day > of use! Then the box is going from the net and its not awailable. I tried to > tune the system with adding more in proc tcp_mem but the problem is still > there the box only lasts for bout 2h longer. > > and i get this in messages > > kernel: TCP: too many of orphaned sockets > > It looks like my system is not droping closed sockets? You can check by using netstat -tan Normally the message is harmless; when it happens the closed sockets are RST instead of being closed properly. -Andi - 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: const __init
On Sun, 20 May 2001, Jeff Garzik wrote:
> Geert Uytterhoeven wrote:
> > Since a while include/linux/init.h contains the line
> >
> > * Also note, that this data cannot be "const".
> >
> > Why is this? Because const data will be put in a different section?
>
> Causes a "section type conflict" build error, at least on x86.
On m68k I only saw section type conflict errors when using __init while it
should have been __initdata.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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: const __init
On Sunday 20 May 2001 21:51, Geert Uytterhoeven wrote: > Since a while include/linux/init.h contains the line > > * Also note, that this data cannot be "const". > > Why is this? Because const data will be put in a different section? Yes, and gcc3 errors on these constructs, cause it cannot decide if the data should be put into a .data or .rodata section. Dunno if it's worth to create a __initconstdata/__initrodata though, but it would be easy implement I guess. > drivers/video/aty128fb.c Fixed in bk 2_4. Franz. - 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: Background to the argument about CML2 design philosophy
Jonathan Morton <[EMAIL PROTECTED]>: > One caveat though - not all Macs have SCSI controllers, and not all that do > even have one of the two standard ones. I know. But these derivations are only for the old 68K macs, which don't have PCI. Closed issue. > >3. The MVME derivations are correct *if* (and only if) you agree to ignore > >the possibility that somebody could want to ignore the onboard hardware, > >plug outboard disk or Ethernet cards into the VME-bus connector, and > >do something like running SCSI-over-ATAPI to the outboard device. > > ...and then someone else mentioned the possibility of f*x0r3d hardware. In > this case, I would say this *isn't* a kernel-configuration issue but one of > being able to disable the drivers for the malfunctioning hardware. But the other side is going to ask: suppose you're memory-limited (quite likely on older SBCs) and don't want to pay the core cost of drivers you won't use? I don't really think we can duck this question by talking about boot-time parameters. > I think the MVME derivations are *perfectly* sensible - if the reference > board and most (read: virtually all) derivatives have those features, turn > them on by all means. That's my gut feeling, too. But a lot of people insist that the only right way is totally fine-grained control, even in weird edge cases like this one. > To satisfy some others, you might want to say "Hey, > these guys might want to *explicitly turn off* some of this stuff" - so > provide an option under "Are you insane?" which presents all the "derived" > symbols and allows the hackers to manually turn stuff off. Interesting thought... -- http://www.tuxedo.org/~esr/;>Eric S. Raymond I cannot undertake to lay my finger on that article of the Constitution which grant[s] a right to Congress of expending, on objects of benevolence, the money of their constituents. -- James Madison, 1794 - 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/
waitqueue problem on 2.4.3
Hy to all !
I am experiencing big problems using wait queues in a device driver
(module)
on kernel 2.4.3-20mdk (gcc version 2.96).
I dont know if this is the right place to ask for - but its my last hope...
The device driver i write is for a measuring device connected to parallel
port-
so i'm using the parport and parport_pc modules with exclusice access to
the
parallel port. Communication with the device works perfectly with one
exception - i cant use waitqueues - it doesnt matter in which was i try it
(i noticed there were changes to waitqueues in 2.4 kernels)...
the first approach using waitqueues looks like this :
hshppm.c: (the driver)
/* ... */
static DECLARE_WAIT_QUEUE_HEAD( hshppm_isr_digital_wq );
/* ... */
static int device_open( struct inode *inode, struct file *file )
{
/* ... */
init_waitqueue_head(_isr_digital_wq);
/* ... */
}
/* ... */
static ssize_t device_read( struct file *file,
char *buffer,
size_t length,
loff_t *offset)
{
/* ... */
interruptible_sleep_on( _isr_digital_wq );
/* ... */
}
/* ... */
/* the ISR for the INTs on the parallel port */
/* called from parport_generic_irq() */
void hshppm_isr( int irq, void *handle, struct pt_regs *regs )
{
/* ... */
wake_up_interruptible( _isr_digital_wq )
/* ... */
}
When I run this code and execute the read() from userland it does a
segfault
when the module executes the interruptible_sleep_on() - a kernel oops is
recorded in the
log:
May 20 21:01:40 ofen kernel: Unable to handle kernel NULL pointer
dereference at virtual address 003d
May 20 21:01:40 ofen kernel: printing eip:
May 20 21:01:40 ofen kernel: c0111c4b
May 20 21:01:40 ofen kernel: pgd entry cae5:
May 20 21:01:40 ofen kernel: pmd entry cae5:
May 20 21:01:40 ofen kernel: ... pmd not present!
May 20 21:01:40 ofen kernel: Oops:
May 20 21:01:40 ofen kernel: CPU:0
May 20 21:01:40 ofen kernel: EIP:0010:[sleep_on+35/88]
May 20 21:01:40 ofen kernel: EIP:0010:[]
May 20 21:01:40 ofen kernel: EFLAGS: 00210086
May 20 21:01:40 ofen kernel: eax: cb53e000 ebx: 00200286 ecx:
00200246 edx: 0039
May 20 21:01:40 ofen kernel: esi: ce071720 edi: 0804b225 ebp:
cb53ff5c esp: cb53ff48
May 20 21:01:40 ofen kernel: ds: 0018 es: 0018 ss: 0018
May 20 21:01:40 ofen kernel: Process dev_test1 (pid: 1842,
stackpage=cb53f000)
May 20 21:01:40 ofen kernel: Stack: ffea cb53e000 cb53e000
c0111554 cb53ff9c e8be7232 e8becaf8
May 20 21:01:40 ofen kernel:e8beb383 e8becadc d6fd4000 d5e75960
40016000 001a ffea d5e75960
May 20 21:01:40 ofen kernel:001a bfffeee8 ffea ce071720
0001 b698 c012dca6 ce071720
May 20 21:01:40 ofen kernel: Call Trace: [process_timeout+0/72]
[] [] [] [] [sys_read+142/196]
[system_call+51/64]
May 20 21:01:40 ofen kernel: Call Trace: [] []
[] [] [] [] []
May 20 21:01:40 ofen kernel:
May 20 21:01:40 ofen kernel: Code: 8b 42 04 8d 4d f8 89 48 04 8d 4a 04 89
4d fc 89 45 f8 8d 4d
i did the init_waitqueue_head() in device_open() when the device is openend
from userland - so this
should not happen...
i tested the above also with the init_waitqueue_head() omitted in
device_open() - cause the
kernel api changes documented in
http://www.atnf.csiro.au/~rgooch/linux/docs/porting-to-2.4.html
say i doesnt need it.
The second approach i tested look like this:
hshppm.c: (the driver)
/* ... */
static DECLARE_WAIT_QUEUE_HEAD( hshppm_isr_digital_wq );
/* ... */
static int device_open( struct inode *inode, struct file *file )
{
/* ... */
init_waitqueue_head(_isr_digital_wq);
/* ... */
}
/* ... */
static ssize_t device_read( struct file *file,
char *buffer,
size_t length,
loff_t *offset)
{
/* ... */
unsigned long flags;
DECLARE_WAITQUEUE (wait, current);
wq_write_lock_irqsave(&(hshppm_isr_digital_wq.lock), flags);
wait.flags = 0;
__add_wait_queue(_isr_digital_wq, );
wq_write_unlock_irqrestore(&(hshppm_isr_digital_wq.lock), flags);
current->state = TASK_INTERRUPTIBLE;
schedule();
current->state = TASK_RUNNING;
wq_write_lock_irqsave(&(hshppm_isr_digital_wq.lock), flags);
__remove_wait_queue(_isr_digital_wq, );
wq_write_unlock_irqrestore(&(hshppm_isr_digital_wq.lock), flags);
/* ... */
}
/* ... */
/* the ISR for the INTs on the parallel port */
/* called from parport_generic_irq() */
void hshppm_isr( int irq, void *handle, struct pt_regs *regs )
{
/* ... */
wake_up_interruptible( _isr_digital_wq )
/* ... */
}
Now wonder ! This time the code in device_read() executes - the process
calling
read() goes to sleep ...
But if an interrupt arrives in
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
> Linus, as much as I'd like to agree with you, you are hopeless optimist. > 90% of drivers contain code written by stupid gits. I think thats a very arrogant and very mistaken view of the problem. 90% of the driver are written by people who are - Copying from other drivers - Using the existing API's to make their job easy - Working to timescales - Just want it to work So if you take ioctl away from them they will implement ioctl emulation by writing ioctl structs to an fd. If you want to make these things work well you have to provide a good working infrastructure. You don't change anything (except the maintainer) by causing pain. Instead you provide the mechanisms - the generic parsing code so that people don't screw up on procfs parsing - the generic ioctl alternatives etc. Ditto with the major numbers. You win that battle by getting enough people to believe it is the right answer that they write the nice code for managing resources and naming assignment - which is already beginning to occur. Then even if I'm still maintaining a major number list in 2 years nobody can quite remember why, and people are heard murmering 'You should have tried Linux two years ago, you had to actually make device files yourself sometimes' Alan - 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: serpent loopback crypto "EXT2-fs: group descriptors corrupted"
spam goes to /dev/null wrote: > i created a 10mb file called .enc2 with random data and ran "# losetup -e > serpent -k 128 /dev/loop0 /mnt/hda7/.enc2" > then i ran "# mke2fs /dev/loop0" and tried to "# mount /dev/loop0 /enc". but > i get the following error messages when trying to mount: > > May 19 21:32:10 HOST2 kernel: EXT2-fs error (device loop(7,0)): > ext2_check_descriptors: Block bitmap for group 16 not in group (block 0)! > May 19 21:32:10 HOST2 kernel: EXT2-fs: group descriptors corrupted ! > > im using kernel 2.4.4 patched with crypto patch 2.4.3.1 [and util linux > 2.11a patched with the patch from that crypto patch] > i also got the same errors with a 2gb file and by creating the loop device > directly on my 19.5gb /dev/hda7 > i tried a few times again and sometimes the encrypted loopback fs works > perfectly, sometimes the error occurs!? > anyone got an idea what this is!? i will supply more information on request International crypto patch is misdesigned and broken, period. If you don't want to play russian roulette with your data, you should consider using loop-AES package. loop-AES announcement is here: http://mail.nl.linux.org/linux-crypto/2001-05/msg3.html Regards, Jari Ruusu <[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: const __init
Geert Uytterhoeven wrote: > > Since a while include/linux/init.h contains the line > > * Also note, that this data cannot be "const". > > Why is this? Because const data will be put in a different section? Causes a "section type conflict" build error, at least on x86. > FWIW, many sources still use __init for data, while it should be __initdata. *blink* wow -- Jeff Garzik | "Do you have to make light of everything?!" Building 1024| "I'm extremely serious about nailing your MandrakeSoft | step-daughter, but other than that, yes." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.4.4-ac11 - dma mapping in drivers/net/fealnx.c
The patch makes the driver use the dma mapping interface.
It compiles.
No adequate adapter for testing.
--- linux-2.4.4-ac11/drivers/net/fealnx.c Sat May 19 14:36:37 2001
+++ linux-2.4.4-ac11/drivers/net/fealnx.c Sun May 20 15:53:26 2001
@@ -46,6 +46,8 @@ static int full_duplex[MAX_UNITS] = { -1
// #define RX_RING_SIZE32
#define TX_RING_SIZE6
#define RX_RING_SIZE12
+#define TX_TOTAL_SIZE TX_RING_SIZE*sizeof(struct fealnx_desc)
+#define RX_TOTAL_SIZE RX_RING_SIZE*sizeof(struct fealnx_desc)
/* Operational parameters that usually are not changed. */
/* Time in jiffies before concluding the transmitter is hung. */
@@ -363,8 +365,11 @@ enum tx_desc_control_bits {
struct netdev_private {
/* Descriptor rings first for alignment. */
- struct fealnx_desc rx_ring[RX_RING_SIZE];
- struct fealnx_desc tx_ring[TX_RING_SIZE];
+ struct fealnx_desc *rx_ring;
+ struct fealnx_desc *tx_ring;
+
+ dma_addr_t rx_ring_dma;
+ dma_addr_t tx_ring_dma;
struct net_device_stats stats;
@@ -461,6 +466,8 @@ static int __devinit fealnx_init_one(str
long ioaddr;
unsigned int chip_id = ent->driver_data;
struct net_device *dev;
+ void *ring_space;
+ dma_addr_t ring_dma;
/* when built into the kernel, we only print version if device is found */
#ifndef MODULE
@@ -528,6 +535,22 @@ static int __devinit fealnx_init_one(str
np->flags = skel_netdrv_tbl[chip_id].flags;
pci_set_drvdata(pdev, dev);
+ ring_space = pci_alloc_consistent(pdev, RX_TOTAL_SIZE, _dma);
+ if (!ring_space) {
+ err = -ENOMEM;
+ goto err_out_free_dev;
+ }
+ np->rx_ring = (struct fealnx_desc *)ring_space;
+ np->rx_ring_dma = ring_dma;
+
+ ring_space = pci_alloc_consistent(pdev, TX_TOTAL_SIZE, _dma);
+ if (!ring_space) {
+ err = -ENOMEM;
+ goto err_out_free_rx;
+ }
+ np->tx_ring = (struct fealnx_desc *)ring_space;
+ np->tx_ring_dma = ring_dma;
+
/* find the connected MII xcvrs */
if (np->flags == HAS_MII_XCVR) {
int phy, phy_idx = 0;
@@ -623,7 +646,7 @@ static int __devinit fealnx_init_one(str
err = register_netdev(dev);
if (err)
- goto err_out_free;
+ goto err_out_free_tx;
printk(KERN_INFO "%s: %s at 0x%lx, ",
dev->name, skel_netdrv_tbl[chip_id].chip_name, ioaddr);
@@ -633,7 +656,11 @@ static int __devinit fealnx_init_one(str
return 0;
-err_out_free:
+err_out_free_tx:
+ pci_free_consistent(pdev, TX_TOTAL_SIZE, np->tx_ring, np->tx_ring_dma);
+err_out_free_rx:
+ pci_free_consistent(pdev, RX_TOTAL_SIZE, np->rx_ring, np->rx_ring_dma);
+err_out_free_dev:
kfree(dev);
err_out_unmap:
#ifndef USE_IO_OPS
@@ -647,7 +674,14 @@ err_out_res:
static void __devexit fealnx_remove_one(struct pci_dev *pdev)
{
struct net_device *dev = pci_get_drvdata(pdev);
+
if (dev) {
+ struct netdev_private *np = dev->priv;
+
+ pci_free_consistent(pdev, TX_TOTAL_SIZE, np->tx_ring,
+ np->tx_ring_dma);
+ pci_free_consistent(pdev, RX_TOTAL_SIZE, np->rx_ring,
+ np->rx_ring_dma);
unregister_netdev(dev);
#ifndef USE_IO_OPS
iounmap((void *)dev->base_addr);
@@ -828,8 +862,8 @@ static int netdev_open(struct net_device
init_ring(dev);
- writel(virt_to_bus(np->rx_ring), ioaddr + RXLBA);
- writel(virt_to_bus(np->tx_ring), ioaddr + TXLBA);
+ writel(np->rx_ring_dma, ioaddr + RXLBA);
+ writel(np->tx_ring_dma, ioaddr + TXLBA);
/* Initialize other registers. */
/* Configure the PCI bus bursts and FIFO thresholds.
@@ -1077,7 +,8 @@ static void allocate_rx_buffers(struct n
break; /* Better luck next round. */
skb->dev = dev; /* Mark as being used by this device. */
- np->lack_rxbuf->buffer = virt_to_bus(skb->tail);
+ np->lack_rxbuf->buffer = pci_map_single(np->pci_dev, skb->tail,
+ np->rx_buf_sz, PCI_DMA_FROMDEVICE);
np->lack_rxbuf = np->lack_rxbuf->next_desc_logical;
++np->really_rx_count;
}
@@ -1168,14 +1203,15 @@ static void init_ring(struct net_device
for (i = 0; i < RX_RING_SIZE; i++) {
np->rx_ring[i].status = 0;
np->rx_ring[i].control = np->rx_buf_sz << RBSShift;
- np->rx_ring[i].next_desc = virt_to_bus(>rx_ring[i + 1]);
+ np->rx_ring[i].next_desc = np->rx_ring_dma +
+ (i + 1)*sizeof(struct fealnx_desc);
np->rx_ring[i].next_desc_logical = >rx_ring[i + 1];
np->rx_ring[i].skbuff = NULL;
}
/* for the last rx descriptor */
- np->rx_ring[i - 1].next_desc
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
[EMAIL PROTECTED] said:
> Now, a good way to force the issue may be to just remove the "ioctl"
> function pointer from the file operations structure altogether. We
> don't have to force peopel to use "read/write" - we can just make it
> clear that ioctl's _have_ to be wrapped, and that the only ioctl's
> that are acceptable are the ones that are well-designed enough to be
> wrappable. So we'd have a "linux/fs/ioctl.c" that would do all the
> wrapping,
I have so far resisted adding an 'ioctl' method to the MTD structure. Yet
because userspace needs to be able to request an erase, request information
about the erasesize of the device, etc., I've got an ioctl wrapper much as
you describe in drivers/mtd/mtdchar.c. It calls _real_ functions like
->erase() in the underlying MTD device, which can't easily be exposed to
userspace (unless we do something silly like using CORBA :)
I can see the advantage of doing what you suggest - add methods to the
struct block_device for the sensible things like HDIO_GETGEO, BLKGETSIZE,
etc. (and anyone suggesting that it's sensible to have the physical block
device driver at all involved in BLKRRPART shall be summarily shot).
But please don't _actually_ put all the ioctl wrappers in fs/ioctl.c. It'd
be a nightmare for the maintainers of the various sections of it.
Besides, what on earth does it have to do with file systems?
Maybe abi/ioctl/{blkdev,mtd,usb,scsi,...}.c ?
Having it outside the directories which are traditionally owned by the
respective subsystem maintainers means that it's far easier to be fascist
about what's added, too.
On a related note - I was actually beginning to consider a dev-private ioctl
for MTD devices, actually for reasons of taste - some stuff like turning
on/off the automatic hardware ECC on the DiskOnChip devices I consider ugly
enough that I didn't want to deal with it in generic code. At least a
dev-private ioctl seemed like it would banish the ugliness into the
offending driver, and be vaguely reusable if any other device turned out to
require such ugliness.
--
dwmw2
-
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: Mail admin notice my 2 cents
Richard Reynolds wrote: > > I would have never signed up for this list, or any other if it didn't give me at > least a few hours worth of email bouncing neither myself, or usa.net is up > 24/7/365, and i wouldn't expect that everyone has a dedicated email server, for > almost any list. plus I have had many problems with the @home's email servers, > if I relied on them I would probibly have been kicked off quite some time ago. > Any _service_ that offers email _should_ have backup MX servers in place. Anythign less is ..well.. stupid. If you're not a service provider and hostyour own dns/mail server, it's your own choice. After all, you'll only be losing your own email and not other people's email. -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [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/
const __init
Since a while include/linux/init.h contains the line
* Also note, that this data cannot be "const".
Why is this? Because const data will be put in a different section?
However, quite some code defines const __init variables (see list below).
So what should be done now?
1. Remove const from __initdata variables
2. Make __inidata work with const variables
FWIW, many sources still use __init for data, while it should be __initdata.
Gr{oetje,eeting}s,
Geert
Appendix: here's the list of affected source files:
arch/arm/kernel/setup.c
arch/m68k/amiga/config.c
arch/ppc/amiga/config.c
arch/ppc/kernel/residual.c
drivers/acorn/net/ether1.c
drivers/acorn/net/ether3.c
drivers/acorn/net/etherh.c
drivers/atm/ambassador.c
drivers/cdrom/cdu31a.c
drivers/char/dsp56k.c
drivers/char/pc110pad.c
drivers/char/qpmouse.c
drivers/char/softdog.c
drivers/ide/buddha.c
drivers/ide/rapide.c
drivers/net/ewrk3.c
drivers/net/hamradio/6pack.c
drivers/net/hamradio/bpqether.c
drivers/net/hamradio/mkiss.c
drivers/net/hamradio/scc.c
drivers/net/hamradio/yam.c
drivers/net/strip.c
drivers/net/tokenring/ibmtr.c
drivers/net/wan/lapbether.c
drivers/net/wan/z85230.c
drivers/pci/names.c
drivers/scsi/seagate.c
drivers/sound/sonicvibes.c
drivers/video/amifb.c
drivers/video/aty128fb.c
drivers/video/atyfb.c
drivers/video/mdacon.c
drivers/video/modedb.c
drivers/video/newport_con.c
drivers/video/promcon.c
drivers/video/riva/fbdev.c
drivers/video/sticon-bmode.c
drivers/video/sticon.c
drivers/video/tdfxfb.c
drivers/video/vgacon.c
drivers/zorro/names.c
net/ax25/af_ax25.c
net/ipv4/ipip.c
net/ipx/af_ipx.c
net/ipx/af_spx.c
net/lapb/lapb_iface.c
net/netrom/af_netrom.c
net/unix/af_unix.c
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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: Getting FS access events
> I'm confused. I've always wondered that before you suspend the state > of a machine to disk, why we just don't throw away unnecessary data > like anything not actively referenced. swsusp does exactly that. - 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: Problems with buslogic and osst driver
> So I have 2 questions: > 1) Does anyone know if Leonard Zubkoff is still around? Leonard was around at OLS last year and working at VA. Its possible he was laid off but I've heard nothing to suggest that so he's probably just busy or on holiday > 2) Is anyone else looking after the BusLogic driver these days? Not afaik but feel free to pitch in - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.4.4-ac11 network drivers cleaning
> > printk("%s\n", version);
> >
> > Not quite as optimal but safer.
>
> I disagree. Don't work around an escape bug in a version string, fix
> it...
A % in a version string might be quite reasonable. You are asking to have
an accident by avoiding it. If you want to fight over 4 bytes, then add
a single constant "%s\n", and #define putk() from 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: VIA's Southbridge bug: Latest (pseudo-)patch
> > If it had been a manufacturer in most respectable areas of business they'd be > > recalling and reissuing components, and paying for the end resllers to notify > > each customer > > This is consumer hardware. Consumer products are optimized for a > good buzzword count per $ ratio. Everything else is secondary. Its what I would describe as lack of enforcement by trading standards bodies, and I suspect what the US would call 'insufficient class action lawsuits' Alan - 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: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, 20 May 2001, Linus Torvalds wrote:
> No, but the point is, everybody _would_ consider it a bug if a
> low-level driver "write()" did anything but touched the explicit buffer.
>
> Code like that would not pass through anybody's yuck-o-meter. People would
> point fingers and say "That is not a legal write() function". Anybody who
> tried to make write() follow pointers would be laughed at as a stupid git.
Linus, as much as I'd like to agree with you, you are hopeless optimist.
90% of drivers contain code written by stupid gits.
> Anybody who makes "ioctl()" do the same is just following years of
> standard practice, and the yuck-o-meter doesn't even register.
Nobody reads the drivers. Because otherwise yuck-o-meters would go off-scale.
How about yuck value of the
* removing a file by writing "-1" into it?
* mkdir() populating directory.
* unlink() not working in said directory.
* rmdir() happily removing it. And freeing all associated structures.
Opened files? What opened files? Whaddya mean, "oops"?
How about sprintf(s + strlen(s), foo)?
How about a collection of b0rken strtoul() implementations? Including one
that contains
switch (...) {
case 48:
case 49:
(all 22 cases)
How about declaring global array and comparing it with NULL?
How about the whole binfmt_misc.c?
Ehh...
Linus, I've been doing exactly that (reading through the large parts of
tree) and trust me, yuck-o-meter was off-scale almost permanently. Level
of idiocy in the obvious bugs is such that I bet you anything that code
had never been really read through by anyone who knew C.
I would love it if more people actually cared to read the fscking code.
Too few are doing that.
And yes, it's a psychological problem, not a technical one. Oh, well...
Sorry about the rant - I've just spent a couple of hours wading through
the piles of excrements in drivers/*. Ouch.
-
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: [RFD w/info-PATCH] device arguments from lookup, partion code
Davem, check the last thing, please. On Sun, 20 May 2001, Alexander Viro wrote: > > On Sun, 20 May 2001, Linus Torvalds wrote: > > > > How about moratorium on new ioctls in the meanwhile? Whatever we do in > > > fs/ioctl.c, it _will_ take time. > > > > Ehh.. Telling people "don't do that" simply doesn't work. Not if they can > > do it easily anyway. Things really don't get fixed unless people have a > > certain pain-level to induce it to get fixed. > > Umm... How about the following: you hit delete on patches that introduce > new ioctls, I help to provide required level of pain. Deal? It still doesn't work. That only makes people complain about my fascist tendencies. See the thread about device numbers, where Alan just says "ok, I'll do it without Linus then". The whole point of open source is that I don't have that kind of power. I can only guide, but the most powerful guide is by guiding the _design_, not micro-managing. > BTW, -pre4 got new bunch of ioctls. On procfs, no less. I know. David has zero taste. Davem, why didn't you just make new entries in /proc/bus/pci and let people do "mmap(/proc/bus/pci//mem)" instead of having idiotic ioctl's to set "this is a IO handle" and "this is a MEM handle"? This particular braindamage is not too late to fix.. 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: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, 20 May 2001, Alexander Viro wrote: > > On Sun, 20 May 2001, Matthew Wilcox wrote: > > > On Sun, May 20, 2001 at 03:11:53PM -0400, Alexander Viro wrote: > > > Pheeew... Could you spell "about megabyte of stuff in ioctl.c"? > > > > No. > > > > $ ls -l arch/*/kernel/ioctl32*.c > > -rw-r--r--1 willywilly 22479 Jan 24 16:59 >arch/mips64/kernel/ioctl32.c > > -rw-r--r--1 willywilly 109475 May 18 16:39 >arch/parisc/kernel/ioctl32.c > > -rw-r--r--1 willywilly 117605 Feb 1 20:35 >arch/sparc64/kernel/ioctl32.c > > > > only about 100k. > > You are missing all x86-only drivers. Now, the point is that it _is_ doable, and by doing it in one standard place (instead of letting each architecture fight it on its own) we'd expose the problem better, and maybe get rid of some of those architecture-specific ones. For example, right now the fact that part of the work _has_ been done by things like Sparc64 has not actually had any advantages: the sparc64 work has not allowed people to say "let's try to merge this work", because it has not been globally relevant, and a sparc64-only file has not been a single point of contact that could be used to clean up things. In contrast, a generic file has the possibility of creating new VFS or device-level interfaces. You can catch block device ioctl's and turn them into proper block device requests - and send them down the right request queue. Suddenly a block device driver doesn't just get READ/WRITE requests, it gets EJECT/SERIALIZE requests too. Without having to add magic ioctl's that are specific to just one device driver. So by having a common point of access, you can actually encourage _fixing_ some of the problems. Historically, sparc64 etc have not been able to do that - they can only try to convert different ioctl's into another format and then re-submitting it.. 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: Mail admin notice my 2 cents
I would have never signed up for this list, or any other if it didn't give me at least a few hours worth of email bouncing neither myself, or usa.net is up 24/7/365, and i wouldn't expect that everyone has a dedicated email server, for almost any list. plus I have had many problems with the @home's email servers, if I relied on them I would probibly have been kicked off quite some time ago. well thats my 2cents Richard Reynolds [EMAIL PROTECTED] On Sun, 20 May 2001, Matti Aarnio wrote: > Date: Sun, 20 May 2001 22:05:45 +0300 > From: Matti Aarnio <[EMAIL PROTECTED]> > To: Mike A. Harris <[EMAIL PROTECTED]> > Cc: Shawn Starr <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: Mail admin notice > > On Sun, May 20, 2001 at 06:28:24AM -0400, Mike A. Harris wrote: > > On Sun, 20 May 2001, Shawn Starr wrote: > > >My emails may bounce between 3AM -> 8AM Est time, @Home is doing some > > >fiber upgrades and i dont have a second MX server (as I am the > > >domain/dns/mail etc). > > There is 3d+ some hours grace period during which vger > doesn't need to be able to feed email to destination > system, BUT AFTER THAT STARTS BOUNCING. > (To linux-kernel-owner, NOT to the list itself!) > > Alan Cox was awhile back offline for 2-3 days, and was > amazed that trans-atlantic connection can feed email > at full bandwidth of his network connection (512k, or > whatever that was..) > > > >Please bear with bounces until then. > > If you are unconnected for more than that 3d+, THEN > you will be removed. For few hours that is no problem. > > Begin connected to the network for few hours every day > is no problem either, but then you would most likely > have backup MX server, and issue an ETRN request for > your domain there when you reconnect. > > > You're saying that you consider it acceptable to bounce email to > > 5000 to 1 people, possibly thousands of messages? And that > > you knew it may occur in advance? I would think the responsible > > thing to do would be to unsubscribe from the mailing list > > temporarily until your problem is solved. Anything less is > > purely apathetic on your part. > > Mike. Don't suggest something of which you apparently > know nothing about. > > > /Matti Aarnio -- co-postmaster of 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/ > > > ,'' '', Richard Reynolds ( 0 0 )La Mesa , Ca oOOo-(_)-oOO___ E-Mail: [EMAIL PROTECTED] IRC: Dalnet #!rsr, rsman --- If you are not an intended reciepient of this message, please accept my appologies, If you recieve more than 1 message that you feel you were not intended to recieve Please feel free to E-Mail me at [EMAIL PROTECTED] So that I can be certain you do not recieve further E-Mails from this address. - 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: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, 20 May 2001, Linus Torvalds wrote: > > How about moratorium on new ioctls in the meanwhile? Whatever we do in > > fs/ioctl.c, it _will_ take time. > > Ehh.. Telling people "don't do that" simply doesn't work. Not if they can > do it easily anyway. Things really don't get fixed unless people have a > certain pain-level to induce it to get fixed. Umm... How about the following: you hit delete on patches that introduce new ioctls, I help to provide required level of pain. Deal? BTW, -pre4 got new bunch of ioctls. On procfs, no less. - 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: F_CTRLFD (was Re: Why side-effects on open(2) are evil.)
On Sun, 20 May 2001, Edgar Toernig wrote: > IMHO any similar powerful (and versatile) interface will see the same > problems. Enforcing a read/write like interface (and rejecting drivers > that pass ptrs through this interface) may give you some knowledge about > the kernel/userspace communication. But the data the flows around will > become the same mess that is present with the current ioctl. Every driver > invents its own sets of commands, its own rules of argument parsing, ... > Maybe it's no longer strange binary data but readable ASCII strings but > that's all. Look at how many different "styles" of /proc files there are. Too many people who don't know C and manage to get their crap into the tree. Shame, but that is _not_ a technical problem. > IMHO what's needed is a definition for "sane" in this context. Trying > to limit the kind of actions performed by ioctls is not "sane". Then > people will always revert back to old ioctl. "Sane" could be: network > transparent, architecture independant, usable with generic tools and non > C-like languages. /me points to UNIX-like OS that had done that. BTW, network-transparent means "no pointers"... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, 20 May 2001, Alexander Viro wrote:
>
> Pheeew... Could you spell "about megabyte of stuff in ioctl.c"?
I agree. But it would certainly force people to think about this. And it
may turn out that a lot of it can be streamlined, and not that much ends
up being used very much.
It would also allow a single place of catching the generic ones, and as
such be a place to try to make things like the network ioctl's more
regular: setting things like network device duplex with _real_ interfaces
instead of hiding it in ioctl routines.
Also, note that many ioctl's actually do have fairly regular meaning, and
that it _is_ possible to catch a number of them with those regular
things:
switch (_IOC_TYPE(number)) {
case 'x':
xfs_ioctl(..);
and actually try to enforce the things that Documentation/ioctl-number.txt
tries to document. And make the clashes _explicit_ and thus make people
have more incentive to really try to fix it.
> How about moratorium on new ioctls in the meanwhile? Whatever we do in
> fs/ioctl.c, it _will_ take time.
Ehh.. Telling people "don't do that" simply doesn't work. Not if they can
do it easily anyway. Things really don't get fixed unless people have a
certain pain-level to induce it to get fixed.
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: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, 20 May 2001, Matthew Wilcox wrote: > On Sun, May 20, 2001 at 03:11:53PM -0400, Alexander Viro wrote: > > Pheeew... Could you spell "about megabyte of stuff in ioctl.c"? > > No. > > $ ls -l arch/*/kernel/ioctl32*.c > -rw-r--r--1 willywilly 22479 Jan 24 16:59 arch/mips64/kernel/ioctl32.c > -rw-r--r--1 willywilly 109475 May 18 16:39 arch/parisc/kernel/ioctl32.c > -rw-r--r--1 willywilly 117605 Feb 1 20:35 arch/sparc64/kernel/ioctl32.c > > only about 100k. You are missing all x86-only drivers. - 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.4.4 del_timer_sync oops in schedule_timeout
On Sun, 20 May 2001, Jacob Luna Lundberg wrote: > > > Unable to handle kernel paging request at virtual address 78626970 > > this appears to be some sort of DMA-corruption or other memory scribble > > problem. hexa 78626970 is ASCII "pibx", which shows in the direction of > > some sort of disk-related DMA corruption. > > we havent had any similar crash in del_timer_sync() for ages. > > Ahh. Thanks then, I'll go look hard at the disk in that box. :) not necesserily the disk. it can be any sort of overheating or other thermal noise (unlikely), or SCSI/IDE cable problem (likely), or driver problem (likely too). Disk faults typically show very different symptoms. Ingo - 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: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, May 20, 2001 at 03:11:53PM -0400, Alexander Viro wrote: > Pheeew... Could you spell "about megabyte of stuff in ioctl.c"? No. $ ls -l arch/*/kernel/ioctl32*.c -rw-r--r--1 willywilly 22479 Jan 24 16:59 arch/mips64/kernel/ioctl32.c -rw-r--r--1 willywilly 109475 May 18 16:39 arch/parisc/kernel/ioctl32.c -rw-r--r--1 willywilly 117605 Feb 1 20:35 arch/sparc64/kernel/ioctl32.c only about 100k. -- Revolutions do not require corporate support. - 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: F_CTRLFD (was Re: Why side-effects on open(2) are evil.)
Alexander Viro wrote: > > On Sun, 20 May 2001, Edgar Toernig wrote: > > > IMHO any scheme that requires a special name to perform ioctl like > > functions will not work. Often you don't known the name of the > > device you're talking to and then you're lost. > > ls -l /proc/self/fd/ Oh come on. You made most of the VFS and should know better. Since when is it possible to always get a "usable" name for an fd??? The ls -l will give me "deleted", "socket", "...". If I try to access the name given by procfs I may get EPERM, etc etc. And then, it's pretty strange to append a "ctl" to some arbitrary name and I get a control device for that name??? No. Using names is __wrong__! > [not going to happen:] > 1) sys_ioctl() going away from syscall table. I would never suggest that. > 2) semi-automatic conversion of existing applications. Same. Much too dangerous. > To hell with > the way we are finding descriptor, we need to deal with arguments themselves. > And no extra logics in libc will help - the whole problem is that ioctls > have rather irregular arguments. Don Quijote II.? ;-) IMHO any similar powerful (and versatile) interface will see the same problems. Enforcing a read/write like interface (and rejecting drivers that pass ptrs through this interface) may give you some knowledge about the kernel/userspace communication. But the data the flows around will become the same mess that is present with the current ioctl. Every driver invents its own sets of commands, its own rules of argument parsing, ... Maybe it's no longer strange binary data but readable ASCII strings but that's all. Look at how many different "styles" of /proc files there are. > What we need is "make it sane", not "inherit as many things from the > old API as possible". And obvious first target is Linux-specific > device ioctls, simply because they have fewer programs using them. You can impose some rules like "must support" commands, something of how arguments are encoded, errors reported and so on. But I wouldn't like to see an SNMP like mess... IMHO what's needed is a definition for "sane" in this context. Trying to limit the kind of actions performed by ioctls is not "sane". Then people will always revert back to old ioctl. "Sane" could be: network transparent, architecture independant, usable with generic tools and non C-like languages. Ciao, ET. - 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.4.4 del_timer_sync oops in schedule_timeout
On Sun, 20 May 2001, Ingo Molnar wrote: > > Unable to handle kernel paging request at virtual address 78626970 > this appears to be some sort of DMA-corruption or other memory scribble > problem. hexa 78626970 is ASCII "pibx", which shows in the direction of > some sort of disk-related DMA corruption. > we havent had any similar crash in del_timer_sync() for ages. Ahh. Thanks then, I'll go look hard at the disk in that box. :) -Jacob -- Only when work uses up all energy and people are too tired to enjoy the persuit of their passions are they ready to be reduced to the passively receptive state suitable for television. - ``The Hacker Ethic'' by Pekka Himanen - 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: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, 20 May 2001, Linus Torvalds wrote: > Now, a good way to force the issue may be to just remove the "ioctl" > function pointer from the file operations structure altogether. We don't > have to force peopel to use "read/write" - we can just make it clear that > ioctl's _have_ to be wrapped, and that the only ioctl's that are > acceptable are the ones that are well-designed enough to be wrappable. So > we'd have a "linux/fs/ioctl.c" that would do all the wrapping, and would > also be able to do all the stuff that is currently done by pretty much > every single architecture out there (ie emulation of ioctl's for different > native modes). Pheeew... Could you spell "about megabyte of stuff in ioctl.c"? > It would probably not be that horrible. Many ioctl's are probably not all > that much used by any real programs any more. The most common ones by far > are the tty ones - and the truly generic ones like "FIONREAD" that it > actually would make sense to generalize more. Networking stuff. It _is_ used. > Catching stuff like EJECT at a higher layer and turning THOSE kinds of > things into real block device operations would clean up drivers and make > them more uniform. > > Would fs/ioctl.c be an ugly mess of some special cases? Yes. But would > that make the ugliness explicit and possibly easier to try to manage and > fix? Very probably. And it would mean that driver writers could not just > say "fuck design, I'm going to do this my own really ugly way". How about moratorium on new ioctls in the meanwhile? Whatever we do in fs/ioctl.c, it _will_ take time. Al - 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: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, 20 May 2001, Russell King wrote: > > On Sun, May 20, 2001 at 11:46:33AM -0700, Linus Torvalds wrote: > > Nobody will expect the above to work, and everybody will agree that the > > above is a BUG if the read() call will actually follow the pointer. > > I didn't say anything about read(). I said write(). Obviously it > wouldn't work for read()! No, but the point is, everybody _would_ consider it a bug if a low-level driver "write()" did anything but touched the explicit buffer. Code like that would not pass through anybody's yuck-o-meter. People would point fingers and say "That is not a legal write() function". Anybody who tried to make write() follow pointers would be laughed at as a stupid git. Anybody who makes "ioctl()" do the same is just following years of standard practice, and the yuck-o-meter doesn't even register. THAT is the importance of psychology. Technology is meaningless. What matters is how people _think_ of it. 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: Mail admin notice
On Sun, May 20, 2001 at 06:28:24AM -0400, Mike A. Harris wrote: > On Sun, 20 May 2001, Shawn Starr wrote: > >My emails may bounce between 3AM -> 8AM Est time, @Home is doing some > >fiber upgrades and i dont have a second MX server (as I am the > >domain/dns/mail etc). There is 3d+ some hours grace period during which vger doesn't need to be able to feed email to destination system, BUT AFTER THAT STARTS BOUNCING. (To linux-kernel-owner, NOT to the list itself!) Alan Cox was awhile back offline for 2-3 days, and was amazed that trans-atlantic connection can feed email at full bandwidth of his network connection (512k, or whatever that was..) > >Please bear with bounces until then. If you are unconnected for more than that 3d+, THEN you will be removed. For few hours that is no problem. Begin connected to the network for few hours every day is no problem either, but then you would most likely have backup MX server, and issue an ETRN request for your domain there when you reconnect. > You're saying that you consider it acceptable to bounce email to > 5000 to 1 people, possibly thousands of messages? And that > you knew it may occur in advance? I would think the responsible > thing to do would be to unsubscribe from the mailing list > temporarily until your problem is solved. Anything less is > purely apathetic on your part. Mike. Don't suggest something of which you apparently know nothing about. /Matti Aarnio -- co-postmaster of 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: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, 20 May 2001, David Woodhouse wrote: > > If that had been done right the first time, you wouldn't have had to either. > For that matter, it's often the case that if the ioctl had been done right > the first time, nobody would have had to fix it up for any architecture. The problem with ioctl's is, let me repeat, not technology. It's people. ioctl's are a way to do ugly things. That's what they have ALWAYS been. And because of that, people don't care about following the rules - if ioctl's followed the rules, they wouldn't _be_ ioctls in the first place, but instead have a good interface (say, read()/write()). Basically, ioctl's will _never_ be done right, because of the way people think about them. They are a back door. They are by design typeless and without rules. They are, in fact, the Microsoft of UNIX. The only way to fix ioctl's is to force people to think about them in another way. Because if you don't, there is always going to be another driver writer who adds his own ioctl because it's the easy way to do whatever he wants without giving it a second of _design_ thought. Now, a good way to force the issue may be to just remove the "ioctl" function pointer from the file operations structure altogether. We don't have to force peopel to use "read/write" - we can just make it clear that ioctl's _have_ to be wrapped, and that the only ioctl's that are acceptable are the ones that are well-designed enough to be wrappable. So we'd have a "linux/fs/ioctl.c" that would do all the wrapping, and would also be able to do all the stuff that is currently done by pretty much every single architecture out there (ie emulation of ioctl's for different native modes). It would probably not be that horrible. Many ioctl's are probably not all that much used by any real programs any more. The most common ones by far are the tty ones - and the truly generic ones like "FIONREAD" that it actually would make sense to generalize more. Catching stuff like EJECT at a higher layer and turning THOSE kinds of things into real block device operations would clean up drivers and make them more uniform. Would fs/ioctl.c be an ugly mess of some special cases? Yes. But would that make the ugliness explicit and possibly easier to try to manage and fix? Very probably. And it would mean that driver writers could not just say "fuck design, I'm going to do this my own really ugly way". 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: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, May 20, 2001 at 11:46:33AM -0700, Linus Torvalds wrote: > Nobody will expect the above to work, and everybody will agree that the > above is a BUG if the read() call will actually follow the pointer. I didn't say anything about read(). I said write(). Obviously it wouldn't work for read()! > Read my email. And read the last line: "psychology is important". I did. I also know that if you give the world enough rope, someone will hang themselves. (Note that because I've thought a way of misusing this in the same was as ioctl, you can bet your bottom dollar that other people will). -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - 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: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, 20 May 2001, Russell King wrote:
>
> On Sat, May 19, 2001 at 08:26:20PM -0700, Linus Torvalds wrote:
> > You're missing the point.
>
> I don't think Richard is actually. I think Richard has hit a nail
> dead on its head.
>
> > It's ok to do "read()/write()" on structures.
>
> Ok, we can read()/write() structures. So someone invents the following
> structure:
>
> struct foo {
> int cmd;
> void *data;
> } foo;
>
> Now they use write(fd, , sizeof(foo)); Haven't they just swapped
> the ioctl() interface for write() instead?
Wrong.
Nobody will expect the above to work, and everybody will agree that the
above is a BUG if the read() call will actually follow the pointer.
Read my email. And read the last line: "psychology is important".
Step #1 in programming: understand people.
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: add page argument to copy/clear_user_page
On Sun, 20 May 2001, Paul Mackerras wrote: > > The patch below adds a page * argument to copy_user_page and > clear_user_page. If you add the page argument, why leave the old arguments lingering there at all? They only create confusion, and add no information. 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/
[PATCH] make drivers/block/ps2esdi.c compile (2.4.4)
Hi.
The following trivial patch against 2.4.4(-ac11) makes ps2esdi compile.
--- linux-244-ac10-clean/drivers/block/ps2esdi.cSat May 19 21:06:29 2001
+++ linux-244-ac10/drivers/block/ps2esdi.c Sun May 20 14:47:04 2001
@@ -953,10 +953,10 @@
break;
}
if(ending != -1) {
- spin_lock_irqsave(io_request_lock, flags);
+ spin_lock_irqsave(_request_lock, flags);
end_request(ending);
do_ps2esdi_request(BLK_DEFAULT_QUEUE(MAJOR_NR));
- spin_unlock_irqrestore(io_request_lock, flags);
+ spin_unlock_irqrestore(_request_lock, flags);
}
} /* handle interrupts */
--
Regards,
Rasmus([EMAIL PROTECTED])
The difference between theory and practice is that, in theory, there is
no difference between theory and practice. -- Anonymous
-
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: Background to the argument about CML2 design philosophy
>1. The Mac derivations were half-right. The MAC_SCC one is good but Macs >can have either of two different SCSI controllers. I fixed that with help >from Ray Knight, who maintains the 68K Mac port. If I understand the "philosophy" correctly, it is still possible to specify additional cards for those Macs which have PCI slots. If so, absolutely fine - I can shove my Adaptec 19160 into my G4 and have it work just as well as it currently does in my Athlon. One caveat though - not all Macs have SCSI controllers, and not all that do even have one of the two standard ones. The "Blue and White G3", the iMac, the PowerBook G3 "Firewire" and later models on these lines all lack a built-in SCSI controller, but many could have one added via PCI or CardBus slots. The PowerBooks 5300 and 190 (and possibly others) use some non-standard P.O.S. hanging off the NuBus, which even mkLinux doesn't know how to drive. However, in these situations, disabling the extra drivers is usually not critical unless you're running low on space somewhere. At that point, you enable the "Are you insane?" module outlined below... >3. The MVME derivations are correct *if* (and only if) you agree to ignore >the possibility that somebody could want to ignore the onboard hardware, >plug outboard disk or Ethernet cards into the VME-bus connector, and >do something like running SCSI-over-ATAPI to the outboard device. >(I missed these possibilities when I wrote the derivations.) ...and then someone else mentioned the possibility of f*x0r3d hardware. In this case, I would say this *isn't* a kernel-configuration issue but one of being able to disable the drivers for the malfunctioning hardware. If I have a PCMCIA controller that reboots the machine as soon as the driver tries to switch it on, I should be able to send a command-line parameter to the kernel which tells it to switch it off *at run-time*. And iff I'm running with hardware which is so f*x0r3d that that isn't enough, I'd either fix the hardware or hack the config files. I don't see the problem. I think the MVME derivations are *perfectly* sensible - if the reference board and most (read: virtually all) derivatives have those features, turn them on by all means. To satisfy some others, you might want to say "Hey, these guys might want to *explicitly turn off* some of this stuff" - so provide an option under "Are you insane?" which presents all the "derived" symbols and allows the hackers to manually turn stuff off. -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -END GEEK CODE BLOCK- - 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: start_thread question...
[EMAIL PROTECTED] said: > I'm implementing start_thread for the VAX port and am wondering does > start_thread have to return to load_elf_binary? I'm working on the > init thread and what is happening is it is returning the whole way > back to the execve caller .. which I know shouldn't happen. Ingo answered that specific question (and that had me puzzled for a while, too :-), but, in the future, you might want to look at UML if you have similar questions. All this stuff works, and it's implemented in terms of the system calls that we all know and love, so you don't have to learn about a totally different piece of hardware in order to figure out what's going on. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4 folks
Hi Peter. > I've trying to move some of my servers to 2.4.4 kernel from > 2.2.x. Everything goes fine, notable perfomance increase > occures, but the problem is I'm really often touch the following > problem: > __alloc_pages: 1-order allocation failed. > __alloc_pages: 1-order allocation failed. > __alloc_pages: 1-order allocation failed. > __alloc_pages: 1-order allocation failed. > __alloc_pages: 1-order allocation failed. > This message may also show 1-order, 0-order, 3-order failures > (only one type at the time). This problems also appeared then I > tried to use 2.4.1-2.4.3 kernels. > This sometimes leads to system hang, sometimes some processes > gets unkillable (even by kill -9) and in some cases I do not see > any bad results from this, but still this does not looks the > right thing to happen. > The problem is the systems this happens on are not short of > memory. Here is the free output for the system I had this > happened this morning: > rat:~ # free > Mem: 10286281025820 2808 0 9340 332412 > -/+ buffers/cache: 684068 344560 > Swap: 2097136 02097136 > Does anyone has any ideas about this problem ? I'm not up to date with the 2.4 series at the moment, but... Looking at the figures you're showing, this looks like you have 1024M of RAM. It used to be necessary to recompile the kernel if you had more than (going from memory) 976M of RAM, where you had to change a configuration option to select 2G of paging space instead of the default 3G thereof, and this looks suspiciously like this problem to me. Can anybody confirm whether this limitation still applies? Best wishes from Riley. - 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/
