I was in a similar boat, and noticed that this field was basically
bogus. It turns out that the fix was put into the kernel sometime after
2.3 started rolling. It's definately in 2.4-test1.
Something to watch out for is that the sys/ucontext.h registers (EIP
f.e) are #defined to different values than they are in reg.h...
And you need to #define __USE_GNU to get to them. Take a peek at the
header file. (this is at least the case with glibc 2.1.2...)
-Chris
On Wed, 31 May 2000 owner-linux-kernel-digest@vger.rutgers.edu wrote:
>
> linux-kernel-digest Wednesday, May 31 2000 Volume 01 : Number 887
>
> In this issue:
>
> CML2 0.2.0
> Re: [PATCH] VM bugfix + rebalanced + code beauty
> RE: Bug in how capabilities
> Re: Linux 2.5 / 2.6 TODO (preliminary)
> Re: Linux 2.5 / 2.6 TODO (preliminary)
> 2.4.0test1-ac6/7, AHA2940, ide_release_dma
> Re: Bertrand Meyer challenges some open-source assumptions
> Re: Linux 2.5 / 2.6 TODO (preliminary)
> SIGSEGV handler
> Re: Linux 2.5 / 2.6 TODO (preliminary)
> Re: [PATCH] VM bugfix + rebalanced + code beauty
> Re: Linux 2.5 / 2.6 TODO (preliminary)
> Re: Linux 2.5 / 2.6 TODO (preliminary)
> Re: Linux 2.5 / 2.6 TODO (preliminary)
> Re: Does /var/shm still need to be mounted?
> Linux 2.5 / 2.6 TODO
> [PATCH] Oops - 2.4.0test1-ac7 - clgenfb.c
> Re: Advertising SuSe on lkml
> root not busy as it should? [was Re: 2.4.0test1-ac4 - mount problem]
> Re: linux routing to multiple providers
> Linux driver for DC10plus video capture card. V 0.2
> Re: Cryptography in the kernel (was: Re: Linux 2.5 / 2.6 TODO (preliminary))
> Re: linux routing to multiple providers
> Re: mtrr and xf86 confusion?
> Re: Cryptography in the kernel (was: Re: Linux 2.5 / 2.6 TODO (preliminary))
> Re: [PATCH] eepro100 device name <-> pci bus/slot/func mapping
> Re: [PATCH] 2.2.X fix ext2 socket filetype
> Re: Cryptography in the kernel (was: Re: Linux 2.5 / 2.6 TODO (preliminary))
> Re: Can't recognize Adaptec APA-1480 with 2.4.0-test1-ac4
> Re: [PATCH] eepro100 device name <-> pci bus/slot/func mapping
> Re: Can't recognize Adaptec APA-1480 with 2.4.0-test1-ac4
> Re: Cryptography in the kernel (was: Re: Linux 2.5 / 2.6 TODO (preliminary))
> mount(2) in 2.3.99pre9!!!
> Re: Announcing CML2, a replacement for the kbuild system
> mremap problems in latest linux kernels
> Re: Announcing CML2, a replacement for the kbuild system
>
> See the end of the digest for information on subscribing to the linux-kernel
> or linux-kernel-digest mailing lists.
>
> ----------------------------------------------------------------------
>
> From: "Eric S. Raymond" <esr@snark.thyrsus.com>
> Date: Wed, 31 May 2000 17:04:36 -0400
> Subject: CML2 0.2.0
>
> CML2 0.2.0 is now available at http://www.tuxedo.org/~esr/kbuild/
>
> Release 0.2.0: Wed May 31 16:53:34 EDT 2000
> * Full atemporal deduction with a baby theorem prover!
> * Whenever/sets are gone from the language. Those deductions
> are now done directly from requires.
> * Setting a symbol may now set symbols in its visibility guard,
> if we can deduce that relationals in the guard must be true.
>
> Alan Cox should now have his "set a driver and watch all the
> requirements turn on" feature.
>
> The documentation has been updated to full describe the new features
> (and the absence of old ones; whenever/sets are now gone from the
> language, having been replaced by requires.)
> - --
> <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>
>
> It is the assumption of this book that a work of art is a gift, not a
> commodity. Or, to state the modern case with more precision, that works of
> art exist simultaneously in two "economies," a market economy and a gift
> economy. Only one of these is essential, however: a work of art can survive
> without the market, but where there is no gift there is no art.
> -- Lewis Hyde, The Gift: Imagination and the Erotic Life of Property
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Christoph Rohland <cr@sap.com>
> Date: 31 May 2000 22:58:08 +0200
> Subject: Re: [PATCH] VM bugfix + rebalanced + code beauty
>
> Rik van Riel <riel@conectiva.com.br> writes:
>
> > I'm testing stuff now, but seem unable to reproduce your
> > observation. However, I *am* seeing high cpu usage by
> > kswapd ;)
>
> I do these tests regularly 8way/8GB and the latest kernel is
> definitely a step back.
>
> > I guess we really want to integrate the SHM swapout routine
> > with shrink_mmap...
>
> I would love to integrate the whole shm page handling into the page
> cache.
>
> Greetings
> Christoph
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: "Linda Walsh" <law@sgi.com>
> Date: Wed, 31 May 2000 15:59:16 -0700
> Subject: RE: Bug in how capabilities
>
> > -----Original Message-----
> > From: Pavel Machek [mailto:pavel@suse.cz]
>
> > So what? I can not execute setuid shell, but I can freely do anything
> > I could do with the shell. I'll add myself to
> > ~root/.ssh/authorized_keys instead of running root shell. This is
> > called security by obscurity.
> >
> > (Still it can be a little bit usefull.)
> > Pavel
> > --
> > I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
> > Panos Katsaloulis describing me w.r.t. patents me at discuss@linmodems.org
> >
> - ---
>
> It's only a piece of the puzzle -- you came in via what route? A daemon
> running with LUID=daemon? Ooooo....LUID daemon is editing files in
> /root. I'd guess that would be a big-time redflag. Or say you
> managed to do an 'su' from user mrevil -- RT-Audit daemon (user-provided)
> detects that LUID=george is editing a root file, user mrevil is not
> in group 'wheel', or 'sysadmins' or is not in a known memory resident
> list of sysadmins -- bad mrevil...action:signal(SIGKILL).
>
> If you are looking for one solution that will solve all your
> problems I have nothing to offer. Think of security features like
> extra bits in an encryption key. The more layers (bits) you add
> the more difficult it is to crack system security. The only
> 100% secure system is one to which no one has access and nothing will
> cause the machine to go out of "secure state" (secure state=off). Not too
> useful. Using a GOOGLE-PLEX (10^(10^100) bit encryption key wouldn't
> be too useful neither since it'd take forever to generate. But
> even 512 bit keys are now vulnerable to cracking with an optoelectronic
> device (TWINKLE, ref. http://cryptome.org/twinkle.eps) -- meaning
> 1024 bit keys are next on the horizon.
>
> I'm just wanting to get Linux *verified*/*certified* as having basic
> levels of security common in all large systems manufacturers -- things
> that are or will be required for us to enter certain marketplaces.
>
> - -linda
>
> - --
> Linda A Walsh | Trust Technology, Core Linux, SGI
> law@sgi.com | Voice: (650) 933-5338
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Alex Buell <alex.buell@tahallah.clara.co.uk>
> Date: Wed, 31 May 2000 21:27:52 +0100 (BST)
> Subject: Re: Linux 2.5 / 2.6 TODO (preliminary)
>
> On Wed, 31 May 2000, Dag Bakke wrote:
>
> > Slightly off-topic, but related: there is a userland tool to monitor
> > S.M.A.R.T. capable drives. Anyone using this?
>
> I'd like to know this as well. My SMART drive is nearing its 3rd year of
> continous use and I'd like to know when it's about to fail!
>
> Cheers,
> Alex
> - --
> The quality of your life will be determined by
> the quality of the people in your life.
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: David Marshall <marshall@athena.net.dhis.org>
> Date: 31 May 2000 16:16:53 -0500
> Subject: Re: Linux 2.5 / 2.6 TODO (preliminary)
>
> Gregory Maxwell <greg@linuxpower.cx> writes:
>
> > On Wed, 31 May 2000, Jan-Benedict Glaw wrote:
> >
> > > On Wed, May 31, 2000 at 03:59:48AM +0200, David Weinehall wrote:
> > > > N IPsec
> > > > N International Kernel-patches
> > >
> > > Do you really think all that crypto stuff should be in a standard kernel?
> > > Even if there's no longer any problem to *export* it from Amerika, there
> > > might be problems *importing* it into more restrictive countries like
> > > China or France or so...
> >
> > France fixed their policy; It's more liberal then the US.
> >
> > Any info on china?
>
> Is there any way that we can further abstract the crypto stuff[1] so that
> the crypto kernel patches are such that they only add files, and
> modifications are done in the mainline kernel tree?
>
> Right now, the biggest problem with the crypto patches is that they
> tend to fail between kernel revisions. There also appears to be a
> problem with header files with Glibc, because the glibc header files
> aren't patched like the ones in the source tree[2]. Of course, modifying
> the Glibc header files directly would be bad.
>
> So to patch 2.3.99, you are stuck trying to find the latest version of
> the patches (2.3.42, as far as I know) and handling the
> rejects. Unless I missed something or I was the victim of a cosmic
> ray, there's some kind of bug introduced when you do this particular
> combination which causes things to lock up after a few seconds of
> heavy disk activity. I haven't plowed through the code and tries to
> debug that yet.
>
> Ideally from what I'm thinking, the crypto patches would just have to
> add linux/crypto.
>
> So perhaps:
>
> N Stubs for crypto code in the kernel.
> N Separate crypto patch which is kept up to date.
> W Some way to cleanly set up the header files so that things relying
> on the modifications made by the patch will work.
>
> [1] I dislike the term "International kernel patch." It sounds like
> the patch adds support for other languages, or some mystic thing
> so that it will run in other countries.
>
> [2] I haven't investigated this one beyond an initial look.
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Wade Hampton <whampton@staffnet.com>
> Date: Wed, 31 May 2000 17:18:30 -0400
> Subject: 2.4.0test1-ac6/7, AHA2940, ide_release_dma
>
> Notes on some kernel tests of 2.4.0test1-ac6/7.
>
> On 2.4.0test1-ac6, I have the 2940 driver included, not
> as a module. At boot time, I get a SCSI timeout waiting
> for target error. This reminds me of some 2940 problems
> a long time ago (in the 2.1 series). 2.3.99-pre5 works
> fine (my last tested kernel). The configuration is nearly
> identical between 2.3.99-pre5 and 2.4.0test1-ac6.
>
> On 2.4.0test-ac6, the name given to the module directory
> is ac5, not ac6. This was fixed with ac7.
>
> When I try to build ac7, at link time I get an undefined
> symbol:
>
> drivers/ide/idedriver.o: in function: ide_unregister
> undefined ref. to ide_release_dma
>
> Cheers,
> - --
> W. Wade, Hampton <whampton@staffnet.com>
> "The front line of defense against such sophisticated viruses is a
> continually evolving computer operating system that attracts the
> efforts of eager software developers," Gates said. =>> Linux!
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Date: Wed, 31 May 2000 17:25:57 -0400
> Subject: Re: Bertrand Meyer challenges some open-source assumptions
>
> Ian Soboroff <ian@cs.umbc.edu>:
> > "Eric S. Raymond" <esr@thyrsus.com> writes:
> >
> >> Ian Soboroff <ian@cs.umbc.edu>:
> >>> [Bertrand Meyer's] bondage-and-discipline ethics to go with a b&d language.
> >>
> >> Heh. Putting it that way is funnier than you know -- because the term
> >> "bondage-and-discipline language" was originated by one of the targets
> >> of Meyer's vitriol.
> >>
> >> (It was me. But it could just as easily have been RMS; he loves the term.)
> >
> > that i didn't know... hah! mind if i ask the context?
>
> - ------------------------------------------------------------------------------
> >From postnews Thu Dec 22 15:07:46 1988
> Newsgroups: comp.lang.misc
> Subject: Re: colon-equal vs equal
> Message-ID: <eWbWj#4OkIf8=eric@snark.UUCP>
> Date: 22 Dec 88 20:02:04 GMT
> References: <3300001@uxg.cso.uiuc.edu>
> Status: RO
>
> In article <3300001@uxg.cso.uiuc.edu>, phil@uxg.cso.uiuc.edu writes:
> > How did the := come into being in languages like Algol, Pascal, and Ada?
>
> It originated with ALGOL-60. The European `bondage-and-discipline' school of
> language design (the people who brought you Algol-68, Pascal, Modula, Ada, and
> Modula-2 and are now having yet another try at getting their mistakes right in
> Modula-3) likes to claim apostolic descent from that language, and
> they've retained := and some of its other crotchets.
> - ------------------------------------------------------------------------------
>
> Eiffel is squarely in this line of descent.
>
> > of course, i have two misgivings about the line... (1) there are a
> > couple things i actually like about Eiffel, and (2) i'm jewish... we
> > invented b&d ethics ;-)
>
> I think of Eiffel as a "one-good-idea" language. The one good idea is
> contract programming.
> - --
> <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>
>
> This would be the best of all possible worlds, if there were
> no religion in it.
> -- John Adams, in a letter to Thomas Jefferson.
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Marcelo Tosatti <marcelo@conectiva.com.br>
> Date: Wed, 31 May 2000 15:25:18 -0300 (BRST)
> Subject: Re: Linux 2.5 / 2.6 TODO (preliminary)
>
> On Wed, 31 May 2000, Arne Thomassen wrote:
>
> > > Linux 2.5 / 2.6 TODO (preliminary)
> > > N Documentation
> > > W Merge ext3
> > > W Merge ReiserFS
> > > N VFS changes
> > > I Get rid of SCSI host template
> > > I Handle replugging
> >
> > W Replace the big kernel lock with more fine-grained locking as far as
> > possible (completely? ;-)
>
> The correct thing to do is to fine-grain when we notice contention.
> Fine-graining "as much as possible" is a direct way to hell.
>
>
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Mohammad Banikazemi <banikaze@cis.ohio-state.edu>
> Date: Wed, 31 May 2000 17:20:37 -0400
> Subject: SIGSEGV handler
>
> I am trying to write a handler for SIGSEGV.
> My handler is of the following form:
>
> void segv_handler(sig, scs)
> int sig;
> struct sigcontext_struct scs;
> {
>
> ...
>
> }
>
> I expect to find the virtual address which caused the SIGSEGV
> in scs.cr2 and based on that my handler is supposed to take an action.
>
> However, in *some* of my programs, this field of scs doesn't contain
> the correct virtual address. Inside my segv_handler routine, I print the
>
> contents of different fields of scs. I have noticed that the virtual
> address
> is sometimes in one of the following fields: scs.esp_at_signal and
> scs.eflags.
>
> The linux kernel version is 2.2.5.
>
> Does anyone know what is going on?
> Any help is greatly appreciated.
>
> - -M.
>
>
> P.S. I posted the same question in comp.os.linux.development.apps and
> some
> one suggested that I use a handler of the following form
>
> void segv_handler(iSig, pSigInfo, pContext)
> int iSig;
> struct siginfo *pSigInfo;
> void *pContext;
> {
> segv_address = pSigInfo->si_addr;
> :
> :
> }
>
> I assume that I have to set the sa_flags to SA_SIGINFO when I set my
> segv_handler to be the segv handler by using the sigaction call. I have
> done this
> but the address I find in pSigInfo->si_addr is incorrect. I am pretty
> sure
> about the address which causes the execution of my segv_handler.
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Marcelo Tosatti <marcelo@conectiva.com.br>
> Date: Wed, 31 May 2000 15:27:44 -0300 (BRST)
> Subject: Re: Linux 2.5 / 2.6 TODO (preliminary)
>
> On Tue, 30 May 2000, Kenneth C. Arnold wrote:
>
> > Linux 2.5 / 2.6 TODO (preliminary)
> > N Documentation
> > W Merge ext3
> > W Merge ReiserFS
> > N VFS changes
> > I Get rid of SCSI host template
> > I Handle replugging
>
> N: finish and merge userbeans (also write userlevel PAM code)
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Rik van Riel <riel@conectiva.com.br>
> Date: Wed, 31 May 2000 18:19:55 -0300 (BRST)
> Subject: Re: [PATCH] VM bugfix + rebalanced + code beauty
>
> On 31 May 2000, Christoph Rohland wrote:
> > Rik van Riel <riel@conectiva.com.br> writes:
> >
> > > I'm testing stuff now, but seem unable to reproduce your
> > > observation. However, I *am* seeing high cpu usage by
> > > kswapd ;)
> >
> > I do these tests regularly 8way/8GB and the latest kernel is
> > definitely a step back.
>
> I have tracked down why. Shrink_mmap uses a bit more CPU
> due to the page aging, but because we really want to free
> an SHM page, shrink_mmap won't find anything suitable (yes,
> aging works) and just waste some CPU before falling through
> to shm_swap.
>
> > > I guess we really want to integrate the SHM swapout routine
> > > with shrink_mmap...
> >
> > I would love to integrate the whole shm page handling into the
> > page cache.
>
> That would be great. If we have this we can weigh page cache,
> swap cache and shm pages equally. Not only will this result in
> better page replacement, but it will also save on kswapd cpu
> usage.
>
> Even better, having this will allow us to (trivially) insert
> the active/inactive queue idea into the kernel, fixing the
> "write stall" problems for a lot of situations.
>
> regards,
>
> Rik
> - --
> The Internet is not a network of computers. It is a network
> of people. That is its real strength.
>
> Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies
> http://www.conectiva.com/ http://www.surriel.com/
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Cesar Eduardo Barros <cesarb@nitnet.com.br>
> Date: Wed, 31 May 2000 18:26:11 -0300
> Subject: Re: Linux 2.5 / 2.6 TODO (preliminary)
>
> I Fix nvram.c so it won't race with rtc.c on SMP (testers needed)
>
> - --
> Cesar Eduardo Barros
> cesarb@nitnet.com.br
> cesarb@dcc.ufrj.br
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: "H. Peter Anvin" <hpa@zytor.com>
> Date: 31 May 2000 14:33:48 -0700
> Subject: Re: Linux 2.5 / 2.6 TODO (preliminary)
>
> Followup to: <Pine.GSO.4.21.0005310346520.12622-100000@khan.acc.umu.se>
> By author: David Weinehall <tao@acc.umu.se>
> In newsgroup: linux.dev.kernel
> >
> > Well, my v2.5/v2.6 list looks something like this:
> >
> > W HFS+
> > N Some sort of Journaling filesystem
> > W ALSA
> >
> > N IPsec
> > N International Kernel-patches
> >
> > Both these assume that we can get a "GO!" from some sort of US authority.
> >
>
> kernel.org already has the requisite GO!, and it has been further
> strengthened by the Bernstein Interpretation Note.
>
> As long as the sources are right there, we can export it.
>
> -hpa
> - --
> <hpa@transmeta.com> at work, <hpa@zytor.com> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: "H. Peter Anvin" <hpa@zytor.com>
> Date: 31 May 2000 14:36:56 -0700
> Subject: Re: Linux 2.5 / 2.6 TODO (preliminary)
>
> Followup to: <20000530211154.A1909@yahoo.com>
> By author: "Kenneth C. Arnold" <kcarnold@yahoo.com>
> In newsgroup: linux.dev.kernel
> >
> > With that said, here's the very preliminary list (the names are the people
> > who submitted the itmes to me):
> >
> >
> > Linux 2.5 / 2.6 TODO (preliminary)
> > N Documentation
> > W Merge ext3
> > W Merge ReiserFS
> > N VFS changes
> > I Get rid of SCSI host template
> > I Handle replugging
> >
>
> N!!!! dev_t resizing. This is absolutely vital for a whole bunch of reasons.
>
> > Replace the cache of filenames in the VFS with a B+ tree
> > algorithm.
>
> B-trees and derivatives are good on-disk structures. They aren't
> particularly optimal in-memory structures.
>
> -hpa
> - --
> <hpa@transmeta.com> at work, <hpa@zytor.com> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: "H. Peter Anvin" <hpa@zytor.com>
> Date: 31 May 2000 14:38:39 -0700
> Subject: Re: Does /var/shm still need to be mounted?
>
> Followup to: <200005310305.e4V35cN14753@jupiter.cs.uml.edu>
> By author: "Albert D. Cahalan" <acahalan@cs.uml.edu>
> In newsgroup: linux.dev.kernel
> >
> >
> > Thomas Molina writes:
> >
> > > 1. Why is /var/shm such a bad place?
> >
> > Maybe /var is a separate filesystem. Some people have scripts
> > that would try to "clean out" /var/shm. In general, the shm
> > filesystem content is completely unrelated to the rest of /var.
> >
> > > 2. Where is the suggested place?
> >
> > Just like the proc and devfs filesystems, this belongs at the top.
> > It really doesn't fit within anything else. Besides, flatter trees
> > are faster and easier to navigate. So, mount it on /shm.
> >
>
> It really doesn't. It belongs in /dev more than anything, just like
> /dev/pts and friends.
>
> -hpa
> - --
> <hpa@transmeta.com> at work, <hpa@zytor.com> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: "Kenneth C. Arnold" <kcarnold@yahoo.com>
> Date: Wed, 31 May 2000 17:42:10 -0400
> Subject: Linux 2.5 / 2.6 TODO
>
> Hi,
>
> As several people have already suggested, and as noted by the number of
> replies I have gotten both from the list and personally, I guess for
> now I can accept the responsibility of maintainer of this TODO.
>
> But I need some help from you if it's going to help the kernel
> development. First, I hope to find a place for it on the web soon,
> but if someone has the space more immediately or at a good location,
> hosting it there would be optimal. If so, email me and I'll give you
> my latest version so as not to bother the list with minor additions.
>
> Also, lots of people have suggested things without giving an importance
> and / or a link / email. If you want a disorganized list, keep on going.
>
> That's about it,
>
> Kenneth
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Francois ROMIEU <romieu@ensta.fr>
> Date: Wed, 31 May 2000 23:58:02 +0200
> Subject: [PATCH] Oops - 2.4.0test1-ac7 - clgenfb.c
>
> my brand new ac7 bzImage just gave me a nice oops on boot. After all,
> I'm not that sure the following two lines were really needed... Some bag left
> anyone ?
>
> - --- linux-2.4.0-test1-ac7.orig/drivers/video/clgenfb.c Wed May 31 16:24:30 2000
> +++ linux-2.4.0-test1-ac7/drivers/video/clgenfb.c Wed May 31 19:28:04 2000
> @@ -2504,8 +2504,6 @@
>
> if (pdev)
> *btype = clgen_pci_probe_list[i - 1].btype;
> - - if (pci_enable_device(pdev))
> - - return NULL;
>
> DPRINTK ("EXIT, returning %p\n", pdev);
> return pdev;
>
> - --
> Ueimor
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Pavel Machek <pavel@suse.cz>
> Date: Wed, 31 May 2000 22:16:01 +0200
> Subject: Re: Advertising SuSe on lkml
>
> Hi!
>
> > > > Well, going to www.linux-usb.org, and then following a link on the first
> > > > page you see is in my opinion a quite easy way to find the USB backport.
> > > >
> > > > Or try Google with the keywords "USB backport" ... the above mentioned
> > > > link comes out first.
> > > Faboulous hindsight, must be Monday morning:)
> > > Still, that was not my issue. Yes, I supposed that patches could be
> > > found. I simply objected to the wording -- Buy the SuSe CD. And, I
> >
> > Well, sorry for wording. It was just
> > 1) I did not like topic
> > 2) "Go buy suse cd" is slightly slower than
> ~~~~~~-- I meant shorter.
> > "http://www.suse.cz/development/backport"
> > ;-). [And original poster seemed like luser to me, so suse CD could be
> > easier for him to handle; I just hope original poster was not you.]
> >
> > My apologies,
> > Pavel
>
> - --
> I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
> Panos Katsaloulis describing me w.r.t. patents me at discuss@linmodems.org
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Pavel Machek <pavel@suse.cz>
> Date: Wed, 31 May 2000 22:10:33 +0200
> Subject: root not busy as it should? [was Re: 2.4.0test1-ac4 - mount problem]
>
> Hi!
>
> > > > filesystem. The latter is fs-dependent and opaque both for mount(8) and
> > > > sys_mount(). To add more fun, we'll need some syntax for loopbacks and
> > >
> > > Some of the MNT flags are not fs dependant - eg MS_RDONLY
> >
> > To add more fun to that - here's the situation with parsing the mount
> > options:
>
> ...
>
> Seems we have problem with root not being busy when it should. My / fs
> is hda1.
>
> root@bug:/# mount /dev/hda1 /mnt
> root@bug:/# cd /mnt/
> root@bug:/mnt# ls
> amnt/ cdrom/ elf/ home/ lib.suse/ mnt/
> overlay/ suse/ var/
> bin/ core etc/ instmnt@ lost+found/
> nohome/ proc/ tmp/ zip/
> boot/ dev/ hdc/ lib/ minicom.log opt/
> sbin/ usr/
> root@bug:/mnt# cd ..
> root@bug:/# umount /mnt
>
> Oops. mount should not have succeeded.
> Pavel
> - --
> I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
> Panos Katsaloulis describing me w.r.t. patents me at discuss@linmodems.org
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: "Matthew G. Marsh" <mgm@paktronix.com>
> Date: Wed, 31 May 2000 16:46:47 -0500 (CDT)
> Subject: Re: linux routing to multiple providers
>
> On Wed, 31 May 2000, Rob Hill wrote:
>
> > Guss,
> >
> > Thanks for your help. I do not know how masq'ing will keep this from
> > working. When I enter my masq'ing rules, I do it per interface. If eth0 is
> > my ISP1 and eth1 is my ISP2, can I do
> >
> > ipchains -A forward -i eth0 -s 192.168.1.0/25 -d 0/0 -j MASQ
> > ipchains -A forward -i eth1 -s 192.168.1.128/25 -d 0/0 -j MASQ
> >
> > and have the lower half use ISP1 and the upper half use ISP2.
> >
> > Do the masq'ing rules interfere with the iproute package?
>
> No. You must bear in mind that the FORWARD chain (where MASQ takes place
> in ipchains) is AFTER the routing tables. So if you had two default routes
> with two different IP src addresses then the output would be per packet
> and the MASQ outgoing address is takenfrom the src command. IE:
>
> I have two addresses 10.1.1.1 and 172.16.1.1 and they are both valid
> default routes. If I have the following:
>
> ip ro add default via 172.16.1.254 src 172.16.1.1
> ipchains -A forward -s internal -d 0/0 -j MASQ
>
> then all outgoing packets will have 172.16.1.1 as the source address. BTW
> I CAN also do:
>
> ip ro add default via 172.16.1.254 src 10.1.1.1
>
> and all outgoing packets have 10.1.1.1 as the source address (IE -
> responses will be returned to 10.x interface)
>
> Make sense?
>
> > Thanks,
> >
> > Rob Hill
> > rhill@thisbox.com
> >
> > ----- Original Message -----
> > From: "Guus Sliepen" <guus@warande3094.warande.uu.nl>
> > To: "Rusty Russell" <rusty@linuxcare.com.au>
> > Cc: <david+validemail@kalifornia.com>; "Rob Hill" <rhill@thisbox.com>
> > Sent: Tuesday, May 30, 2000 4:05 AM
> > Subject: Re: linux routing to multiple providers
> >
> >
> > > On Fri, 26 May 2000, Rusty Russell wrote:
> > >
> > > > In message <Pine.LNX.4.21.0005242034450.611-100000@haplo.sliepen.oi> you
> > write:
> > > > > ip route add default gw nexthop dev eth0 via <ISP1 gateway> nexthop
> > dev
> > > > > eth1 via <ISP2 gateway>
> > >
> > > > Just a quick note: this won't work in his case, since masquerading
> > > > uses the route to figure what address to map the packets onto: hence
> > > > you need all packets in a given connection to go out the same
> > > > interface. At best, it will sometimes send out packets with eth0's
> > > > source address out eth1. At worst, it will screw things up
> > > > completely.
> > >
> > > Ah, true. I completely forgot about masquerading. But when exactly are the
> > > NAT rules applied wrt. the routing rules?
> > >
> > > > Just make sure the same source IPs get routed the same way, always!
> > >
> > > For real load balancing (of even a single TCP stream), I made a patch
> > > which clearly does exactly the opposite :) But in most situations I'd
> > > agree with you.
> > >
> > > Met vriendelijke groet,
> > > Guus Sliepen.
> > >
> >
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.rutgers.edu
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
> - --------------------------------------------------
> Matthew G. Marsh, President
> Paktronix Systems LLC
> 1506 North 59th Street
> Omaha NE 68104
> Phone: (402) 932-7250
> Email: mgm@paktronix.com
> WWW: http://www.paktronix.com
> - --------------------------------------------------
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Serguei Miridonov <mirsev@cicese.mx>
> Date: Wed, 31 May 2000 14:49:12 -0700
> Subject: Linux driver for DC10plus video capture card. V 0.2
>
> Hello,
>
> I'm glad to announce new release of Linux driver for DC10plus video capture card.
> Now it is even more capable.
>
> Please, visit http://www.cicese.mx/~mirsev/Linux/DC10plus/ for more information.
>
> News:
>
> May 31, 2000: v 0.2
>
> Changes from v 0.1:
>
> 1. TV encoder code has been fixed to operate correctly in PAL standard.
> 2. Full motion decompression is finally working! Now you can record and
> play back your clips in AVI MJPEG or Quicktime format using lavtools
> (see below). You even can play back your movie files captured in
> Windows with Studio. Both NTSC and PAL standards should be supported.
>
> Known problems:
>
> 1. If you are planning to use lavtools to capture your video, you need to
> apply patch (read Tools and utilities section below). This is not a
> driver problem, lavtools have been written for ITU-R.601 image format,
> and DC10plus card can provide only square pixel format. This is a
> hardware limitation imposed by SAA7110 TV decoder.
> 2. To capture full motion video with lavtools in PAL standard you may need
> to add an option -f A (reverse fields, see lavtools distribution for
> more information). I don't know yet where the bug is hidden, it may be
> the driver or lavtools...
> 3. Sometimes when the driver has just been loaded into memory, before
> using lavrec utility first time you may need to run xawtv just once.
> Otherwise, lavrec may not be able to start capture video. I have
> noticed this behavior only with PAL signal.
> 4. When the system speed is not enough to maintain data rate of compressed
> video stream, it seems that dropped (lost) frames are not counted by
> lavrec, so it waits forever for frames from the driver even if driver
> has finished capturing video. In this state one can only kill lavrec by
> SIGKILL to get rid of it. It could be also driver issue, I will be
> looking into it.
> 5. The driver now works only with DC10plus cards which have ADV7176 TV
> encoder. If you have different chip ADV7175 or another version of DC10,
> try to change the i2c address (I2C_ADV7175 macro) in adv7175.c file. It
> can be one of these: 0xD4, 0xD6, 0x54, 0x56. After that recompile the
> module, try to load the driver and see your syslog file or use dmesg to
> check if the chip is detected. In the next version I will try to make
> automatic search for this hardware.
>
> Hopefully, these problems will be fixed soon. Now, since the driver seems to
> be working properly, I will focus on the interaction between the driver and
> software. If you have any idea or can suggest some patches (which is better
> ;-) for any application or to the driver itself, you are always welcome.
> However, to make this work more productive, I would suggest, first of all,
> to discuss your ideas and patches for specific application with a maintainer
> of that application. Read Tools and utilities section below.
>
>
> Tools and utilities
>
> I used two main tool sets to test the driver: xawtv and lavtools. Xawtv
> allows you to watch real-time video on a computer monitor if your video card
> supports overlays. Lavtools (the lavrec utility) can be used to capture full
> motion compressed video and audio, and save it on a disc in AVI MJPEG
> format, so it can be played later by xanim program. Lavtools provide also
> lavplay utility to play back captured video using hardware decompression and
> this feature is supported by the current DC10plus driver.
>
> Before using these utilities with DC10plus board and this driver, I would
> recommend to read installation and usage instructions supplied with these
> tools. Please note, however, that DC10plus card supports only square pixel
> format. In contrast, the majority of TV related programs operate by default
> in ITU-R.601 recommended format which is different. The basic image size for
> DC10plus card is 640x480 (NTSC) and 768x576 (PAL) when both TV fields are
> captured at full resolution. Resolutions 320x240 (NTSC) and 384x288 (PAL)
> are also supported. So, to run the tools mentioned above successfully with
> this driver you will need to do some additional work:
>
> xawtv, to work in NTSC standard, can be started with an additional
> option '-geometry 640x480' or '-geometry 320x240'. Accordingly,
> for PAL standard, set xawtv geometry to 768x576 or 384x288.
> Instead of running xawtv with additional options, you may add the
> following line to your .Xdefaults file:
>
> Xawtv*geometry: <put appropriate format here>
>
> Unfortunately, I had experienced some problems with xawtv
> regarding its interaction with the driver. I believe that this is
> not a driver issue, so probably some work should be done to xawtv
> source. Just in case you have similar problems, read this: If you
> run xawtv program and see nothing but black window on your screen,
> click on this window with right mouse button and change TV
> standard to proper one using pull down menu. If nothing happens,
> quit or kill xawtv, turn off your TV source or disconnect it from
> the DC10plus board and try to run xawtv again. Then, while the TV
> source is still disconnected, try to set proper TV standard and
> then turn the TV source on, or connect it to DC10plus board. Now
> the TV image should appear on the screen.
>
> lavtools, in order to work with DC10plus board, must be patched to
> operate correctly in square pixel format. The patch against
> lavtools version 1.2 is available. Visit the driver homepage for
> more information.
>
>
> General information about DC10plus video capture card
>
> The DC10plus card is manufactured by Pinnacle Systems Inc. and is considered
> by this company as low end product for home use. Currently the company
> provides very easy to use Studio software with only Windows 95/98 drivers
> for the card (even Windows NT/2000 is not supported). However, the hardware
> itself may sometimes satisfy even professional: the frame resolution can be
> up to 640x480, for NTSC, and, 768x576 for PAL standards, which is better
> than Super-VHS (400 vertical lines). The MJPEG hardware compression provides
> the ability to capture and play back full motion (50/60 fields per second)
> video with data rates below 10 MB/s, at compression ratio about 3 for very
> good image quality at full resolution, or even below 2.5 MB/s for acceptable
> VHS like or better image quality. The current price ($149.00 in USA) and
> card characteristics make this card very attractive even for beginners.
>
> Multisystem PAL/NTSC capability: Pinnacle Systems Inc. insists that DC10plus
> cards sold in USA are for NTSC only and the cards sold in Europe and
> Australia are both PAL and NTSC... Well, I can not tell for every card sold
> in USA but at least one of them (guess which one? ;-) supports both PAL and
> NTSC, however, the drivers for Windows 95/98 supplied in the box, and then
> upgraded to version 1.05, support NTSC only. Current Linux driver supports
> both PAL and NTSC standards.
>
> Pinnacle Systems Inc. does not release neither Windows driver source code,
> nor the card programming specifications. This makes writing the driver a bit
> difficult and that's why some features are not yet supported.
> Luckily, complete information is available about chipsets used in this card:
>
> 1. Philips SAA7110A video decoder;
> 2. Zoran ZR36060 (hardware JPEG codec) and ZR36067 (PCI controller);
> 3. Analog Devices ADV7176 video encoder.
>
> If someone would like to play with the driver code and add new features,
> please note that the same or similar JPEG codecs and PCI controllers are
> used in the Iomega Buz and LML33 cards. You may also take a look at Zoran
> H33 board (see also here). This might help somehow... However, the
> programming of different modes of operation depends on specific board design
> and this information for DC10plus card is still missing.
>
> Visit http://www.cicese.mx/~mirsev/Linux/DC10plus/ for more information
> and links.
>
> ------------------------------------------------------------------
>
> Copyright © Serguei Miridonov, 2000. You may redistribute this document as
> long as you keep it in its current form, without any modifications. Please
> keep it updated if you decide to place it on a publicly accessible server.
>
> This page is intended for information purposes only, it may contain errors,
> or inaccurate material. Author of this page will not be held responsible
> for any damage -- direct or indirect -- which may result from inaccuracies.
>
> All statements about businesses and/or corporations and/or everything else
> are being offered as opinions of the author of this page only.
>
> All trademarks and trade names used on this page are the properties of their
> respective owners.
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Russell King <rmk@arm.linux.org.uk>
> Date: Wed, 31 May 2000 22:48:44 +0100 (BST)
> Subject: Re: Cryptography in the kernel (was: Re: Linux 2.5 / 2.6 TODO (preliminary))
>
> Ed Carp writes:
> > Some "laws" are unjust and evil. Just because there is a law doesn't make it
> > right.
>
> But just because its evil does not mean you have to force people to break
> the law, or restrict their ability to use stuff.
>
> > Governments that try to ban even the most basic rights (like that of privacy)
> > using the excuse of "national security" are evil and have no right to even
> > exist.
>
> They do exist, and we have to work around it in a way that is acceptable
> to everyone, unless we're trying to get a smaller Linux user-base.
>
> Is it your intention to restrict the number of users of Linux, or to change
> governments. If its the latter, you'll probably fail miserably.
> _____
> |_____| ------------------------------------------------- ---+---+-
> | | Russell King rmk@arm.linux.org.uk --- ---
> | | | | http://www.arm.linux.org.uk/~rmk/aboutme.html / / |
> | +-+-+ --- -+-
> / | THE developer of ARM Linux |+| /|\
> / | | | --- |
> +-+-+ ------------------------------------------------- /\\\ |
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: "Matthew G. Marsh" <mgm@paktronix.com>
> Date: Wed, 31 May 2000 16:53:56 -0500 (CDT)
> Subject: Re: linux routing to multiple providers
>
> On Wed, 31 May 2000, Guus Sliepen wrote:
>
> > On Wed, 31 May 2000, Rob Hill wrote:
> >
> > > Thanks for your help. I do not know how masq'ing will keep this from
> > > working. When I enter my masq'ing rules, I do it per interface. If
> > > eth0 is my ISP1 and eth1 is my ISP2, can I do
> > [...]
> > > Do the masq'ing rules interfere with the iproute package?
> >
> > It's not a matter of interference, it's a matter of priority. Which rules
> > will be applied first? The ipchains or the iproute rules? In my example,
> > masquerading should be done after iproute rules were applied. I really
> > don't know wether that is so or not. (I _guess_ it _does_ work.)
>
> Just to clarify - under 2.2 with ipchains (almost similar for netfilter)
> the ordering is:
>
> - ---> RPDB (ip rule/route db) ---> FORWARD chain
>
> So you are right - MASQ is applied after iproute.
>
> > Met vriendelijke groet,
> > Guus Sliepen.
> > -
>
> - --------------------------------------------------
> Matthew G. Marsh, President
> Paktronix Systems LLC
> 1506 North 59th Street
> Omaha NE 68104
> Phone: (402) 932-7250
> Email: mgm@paktronix.com
> WWW: http://www.paktronix.com
> - --------------------------------------------------
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: "H. Peter Anvin" <hpa@zytor.com>
> Date: 31 May 2000 14:56:01 -0700
> Subject: Re: mtrr and xf86 confusion?
>
> Followup to: <Pine.LNX.4.21.0005311410560.1610-100000@badlands.lexington.ibm.com>
> By author: Richard A Nelson <cowboy@vnet.ibm.com>
> In newsgroup: linux.dev.kernel
> >
> > I get this from the xdm log:
> > ...
> > (--) SVGA: PCI: S3 Savage4 rev 2, Memory @ 0xfeb80000, 0xf0000000
> > (--) SVGA: SAVAGE: Savage4 rev 2, Linear FB @ 0xfeb80000
> > (--) SVGA: Detected S3 Savage4
> > (--) SVGA: using driver for chipset "s3_savage"
> > (--) SVGA: videoram: 8192k
> > (--) SVGA: Ramdac speed: 250 MHz (220 MHz for 32 bpp)
> > (--) SVGA: Detected current MCLK value of 109.773 MHz
> > (--) SVGA: VBE Version 2.0
> > (--) SVGA: BIOS label is "S3 Incorporated. Savage4"
> > ...
> >
> > But, I can't set the mtrr as per /usr/src/linux/Documentation/mtrr.txt:
> > echo "base=0xfeb80000 size=0x800000 type=write-combining" > /proc/mtrr
> > kernel: mtrr: base(0xfeb80000) is not aligned on a size(0x800000) boundary
> >
>
> You have a zero too much in your "size=" argument.
>
> -hpa
> - --
> <hpa@transmeta.com> at work, <hpa@zytor.com> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: James Sutherland <jas88@cam.ac.uk>
> Date: Wed, 31 May 2000 22:57:46 +0100 (BST)
> Subject: Re: Cryptography in the kernel (was: Re: Linux 2.5 / 2.6 TODO (preliminary))
>
> On Wed, 31 May 2000, Ed Carp wrote:
> > Stuart Lynne (sl@whiskey.fireplug.net) writes:
> > > In article <20000531161727.A10871@frodo.rrze.uni-erlangen.de>,
> > > Walter Hofmann <walter.hofmann@physik.stud.uni-erlangen.de> wrote:
> > > >On Wed, 31 May 2000, Jan-Benedict Glaw wrote:
> >
> > > >Crypto is OK for most countries now. We should aim at including crypto
> > > >in the kernel and provide a patch that _removes_ it for those countries
> > > >that restrict the use or import of cryptogrphy.
> > > >
> > > >Making such a patch is as easy as reversing the patches that add
> > > >cryptography. It also shifts the work to those who oppose
> > > >cryptography; rightfully so IMO.
> > >
> > > Having a patch to remove something an end user cannot have will not work.
> > >
> > > The end user would still end up (briefly) having the illegal version.
> >
> > Some "laws" are unjust and evil. Just because there is a law doesn't make it
> > right.
>
> Unfortunately, the law being "unjust and evil" (IYHO) doesn't stop it
> being the law. Breaking it still has unpleasant consequences for the
> culprit. If you make using Linux illegal in that country, you're just
> surrendering that chunk of Linux's potential audience/market - for what?
>
> > > If we wish to support end users in countries that cannot import crypto
> > > then they must have access to a tarball that does not have crypto.
> >
> > I think we ought to do just the opposite - embed crypto so thoroughly in the
> > kernel that they'd *never* get it out... :)
> >
> > Governments that try to ban even the most basic rights (like that of privacy)
> > using the excuse of "national security" are evil and have no right to even
> > exist.
>
> I agree - but breaking the law (or, in this case, using the law to make
> the use of Linux illegal in that country) doesn't get us anywhere.
>
>
> James.
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Jeff Garzik <jgarzik@mandrakesoft.com>
> Date: Wed, 31 May 2000 17:57:59 -0400
> Subject: Re: [PATCH] eepro100 device name <-> pci bus/slot/func mapping
>
> Anton Blanchard wrote:
> > --- linux/drivers/net/eepro100.c Tue May 23 13:11:19 2000
> > +++ linux_work/drivers/net/eepro100.c Wed May 31 11:20:47 2000
> > @@ -838,6 +844,10 @@
> >
> > pdev->driver_data = dev;
> >
> > +#ifndef USE_IO
> > + dev->mem_start = pci_resource_start(pdev, 0);
> > + dev->mem_end = dev->mem_start + pci_resource_len(pdev, 0);
>
> Use pci_resource_end, avoid the unnecessary addition.
>
>
> > +#endif
> > dev->base_addr = ioaddr;
> > dev->irq = irq;
>
> Why is the dev->base_addr assignment not conditional on USE_IO as well?
>
> Or be more specific,
> 1) What are the semantics of mem_{start,end} versus base_addr? And,
> 2) Why does ifconfig truncate a valid 32-bit address, when
> dev->base_addr equals something like 0xF1234567? I noticed this but
> never got around to looking into the reason.
>
> In any case, you point out something that needs to be fixed in many
> drivers...
>
> Jeff
>
>
>
>
> - --
> Jeff Garzik | Liberty is always dangerous, but
> Building 1024 | it is the safest thing we have.
> MandrakeSoft, Inc. | -- Harry Emerson Fosdick
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
> Date: Wed, 31 May 2000 18:11:16 -0400
> Subject: Re: [PATCH] 2.2.X fix ext2 socket filetype
>
> Alan Cox wrote:
> > > can you please add the following patch into the 2.2.16-pre tree. It is a
> > > back-port of a fix in 2.3 which adds the missing de->file_type information
> > > for sockets in ext2. Without this patch, e2fsck complains about all
> >
> > I passed this on to Stephen and Ted but never got a defintive yes/no
> > answer. Speak now folks or I'll guess myself
>
> Hmm... I must have lost the e-mail, since I don't remember seeing it.
>
> If it's straightfowrad backport of the 2.3 patch, it should be fine.
>
> - Ted
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: David Marshall <marshall@athena.net.dhis.org>
> Date: 31 May 2000 17:13:02 -0500
> Subject: Re: Cryptography in the kernel (was: Re: Linux 2.5 / 2.6 TODO (preliminary))
>
> sl@whiskey.fireplug.net (Stuart Lynne) writes:
>
> > In article <20000531161727.A10871@frodo.rrze.uni-erlangen.de>,
> > Walter Hofmann <walter.hofmann@physik.stud.uni-erlangen.de> wrote:
> > >On Wed, 31 May 2000, Jan-Benedict Glaw wrote:
> > >
> > >> Do you really think all that crypto stuff should be in a standard kernel?
> > >> Even if there's no longer any problem to *export* it from Amerika, there
> > >> might be problems *importing* it into more restrictive countries like
> > >> China or France or so...
> > >
> > >AFAIK France dropped that part of its legislation.
> > >
> > >Crypto is OK for most countries now. We should aim at including crypto
> > >in the kernel and provide a patch that _removes_ it for those countries
> > >that restrict the use or import of cryptogrphy.
> > >
> > >Making such a patch is as easy as reversing the patches that add
> > >cryptography. It also shifts the work to those who oppose
> > >cryptography; rightfully so IMO.
> >
> > Having a patch to remove something an end user cannot have will not work.
> >
> > The end user would still end up (briefly) having the illegal version.
> >
> > If we wish to support end users in countries that cannot import crypto
> > then they must have access to a tarball that does not have crypto.
>
> Perhaps there's a "best of both worlds" approach to be had here. If we
> want the main kernel source tree to have the crypto, and we assume
> that crypto can be removed by the reverse application of a patch,
> then we can have "totalitarian" versions of the Linux source tree which
> have the cryptography already removed. People in the crypto-restricted
> countries can download this version of the tree, while everyone else
> can use the crypto tree.
>
>
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Jeff Garzik <jgarzik@mandrakesoft.com>
> Date: Wed, 31 May 2000 18:16:42 -0400
> Subject: Re: Can't recognize Adaptec APA-1480 with 2.4.0-test1-ac4
>
> David Hinds wrote:
> >
> > On Wed, May 31, 2000 at 06:28:12PM -0700, Michael D. Crawford wrote:
> >
> > > May 31 18:14:56 kingofswing cardmgr[50]: no product info available
> >
> > This is the key, I think. I think the problem is that the 2.3 hot
> > plug PCI code does not enable the PCI expansion ROM... but the PCMCIA
> > drivers want to use this to identify the card.
>
> hmmm. I remember this being discussed, but I thought Martin fixed
> this. Xircom cards need the expansion ROM mapped during init and then
> unmapped, and Martin was talking about a fix for that.
>
> Jeff
>
>
>
> - --
> Jeff Garzik | Liberty is always dangerous, but
> Building 1024 | it is the safest thing we have.
> MandrakeSoft, Inc. | -- Harry Emerson Fosdick
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Anton Blanchard <anton@linuxcare.com>
> Date: Wed, 31 May 2000 15:26:08 -0700
> Subject: Re: [PATCH] eepro100 device name <-> pci bus/slot/func mapping
>
>
> > Use pci_resource_end, avoid the unnecessary addition.
>
> Good point.
>
> > Why is the dev->base_addr assignment not conditional on USE_IO as well?
>
> OK, to be consistent it should not be.
>
> > Or be more specific,
> > 1) What are the semantics of mem_{start,end} versus base_addr? And,
> > 2) Why does ifconfig truncate a valid 32-bit address, when
> > dev->base_addr equals something like 0xF1234567? I noticed this but
> > never got around to looking into the reason.
>
> I do not know the intended semantics, but someone decided that a short was
> enough to store the base address:
>
> struct ifmap
> {
> unsigned long mem_start;
> unsigned long mem_end;
> unsigned short base_addr;
> unsigned char irq;
> unsigned char dma;
> unsigned char port;
> /* 3 bytes spare */
> };
>
> So we have to use mem_start/end for this.
>
> Anton
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: "Michael D. Crawford" <crawford@goingware.com>
> Date: Thu, 01 Jun 2000 07:56:03 -0700
> Subject: Re: Can't recognize Adaptec APA-1480 with 2.4.0-test1-ac4
>
> If there was a patch for this before, maybe it got misplaced somehow?
>
> Perhaps you could tell me how I might dig it up (maybe from a mailing
> list archive) and I could screw around with the code that was submitted
> before and see it fixes my problem.
>
> It happens that I plan to buy a Xircom R56G global PCMCIA modem. Hmm.
> Except I plan to get pcmcia rather than cardbus for compatibility with
> the BeOS, and testing with a PCMCIA card is a totally different beast.
>
> Mike Crawford
> GoingWare Inc. - Expert Software Development Development and Consulting
> http://www.goingware.com
> crawford@goingware.com
>
> Tilting at Windmills for a Better Tomorrow.
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
> Date: Thu, 1 Jun 2000 00:27:21 +0200
> Subject: Re: Cryptography in the kernel (was: Re: Linux 2.5 / 2.6 TODO (preliminary))
>
> - --uxuisgdDHaNETlh8
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: quoted-printable
>
> On Wed, May 31, 2000 at 01:36:45PM -0500, Ed Carp wrote:
> > Stuart Lynne (sl@whiskey.fireplug.net) writes:
> >=20
> > I think we ought to do just the opposite - embed crypto so thoroughly in =
> the
> > kernel that they'd *never* get it out... :)
> >=20
> > Governments that try to ban even the most basic rights (like that of priv=
> acy)
> > using the excuse of "national security" are evil and have no right to even
> > exist.
>
> Maybe they have no right (from our point of view) to exist, but you
> should notive that they *exist*.
>
> We should have a patch or externally compiled modules (I thinks of
> something like the "idea" module for GnuPG which is only available
> as external source). However, such modules need some kind of stable
> API...
>
> MfG, JBG
>
> - --=20
> Fehler eingestehen, Gr=F6=DFe zeigen: Nehmt die Rechtschreibreform zur=FCck=
> !!!
> /* Jan-Benedict Glaw <jbglaw@lug-owl.de> -- +49-177-5601720 */
> keyID=3D0x8399E1BB fingerprint=3D250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 83=
> 99 E1BB
> "insmod vi.o and there we go..." (Alexander Viro on linux-kernel)
>
> - --uxuisgdDHaNETlh8
> Content-Type: application/pgp-signature
>
> - -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.1 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iEYEAREBAAYFAjk1kckACgkQHb1edYOZ4bvtdwCfVa68iwNIlgyh8r4z8h4UFlOU
> REUAoIL6UuHBaywLnp/kaTxW2wX3WiEL
> =KpLh
> - -----END PGP SIGNATURE-----
>
> - --uxuisgdDHaNETlh8--
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Chris Evans <chris@ferret.lmh.ox.ac.uk>
> Date: Wed, 31 May 2000 23:34:20 +0100 (BST)
> Subject: mount(2) in 2.3.99pre9!!!
>
> Hi,
>
> I notice that in 2.3.99pre9 and newer, the system call mount(2) will under
> some circumstances allow unprivileged users to mount things.
>
> Can anyone elaborate on what precisely we allow and why? Despite being
> named "do_loopback", it looks like a simple aliasing mechanism.
>
> At the very least, mount_is_safe() would seem to be missing a check for
> write permission on the parent directory of the mount-point.
>
> Cheers
> Chris
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Russell King <rmk@arm.linux.org.uk>
> Date: Wed, 31 May 2000 23:29:04 +0100 (BST)
> Subject: Re: Announcing CML2, a replacement for the kbuild system
>
> willy@thepuffingroup.com writes:
> > I'm not sure that this is the right way to do it. I prefer a more
> > profile-based approach -- I should be able to just select `IBM' then
> > `Thinkpad 600E' and then go and select my expansion cards. If someone
> > self-builds a machine, then they could start out with `Generic PCI-based
> > x86' and go from there; if they built the machine they should know what's
> > in it.
>
> I agree here - talking for a smaller community.
>
> In the ARM tree, we keep a set of "default sensible configurations" for
> each type of machine so that there is a baseline configuration that we
> know works. We can then add to/remove from that configuration during
> subsequent make *config runs.
>
> However, in the ARM case, there are a lot of architectures where I guess
> around 60% of the questions that the current configuration system asks
> where these are not relevent for one reason or another.
>
> An extreme case is the EBSA110 and NetWinder architectures. The physical
> hardware is like a laptop - its fixed. You can't plug PCI or ISA cards in.
> In fact, the EBSA110 doesn't have PCI or ISA buses, so all PCI and ISA
> net, SCSI, sound drivers and associated options are irrelevent, but you
> still have to say "N" to them.
>
> I've not really paid attention to this thread before, so please mind the
> stupid question - with CML2, is it possible to offer the user a choice
> of machines, and, during the same config session load a new set of defaults
> relating to this new choice of machine? Or even better, disable the
> selection of options which are meaningless for that machine?
> _____
> |_____| ------------------------------------------------- ---+---+-
> | | Russell King rmk@arm.linux.org.uk --- ---
> | | | | http://www.arm.linux.org.uk/~rmk/aboutme.html / / |
> | +-+-+ --- -+-
> / | THE developer of ARM Linux |+| /|\
> / | | | --- |
> +-+-+ ------------------------------------------------- /\\\ |
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Andrey Slepuhin <pooh@msu.ru>
> Date: Thu, 01 Jun 2000 02:49:51 +0400
> Subject: mremap problems in latest linux kernels
>
> Hi,
>
> We tried to test mremap with new MREMAP_FIXED flag and found
> a strange behaviour: the following small program
>
> - ------------- 8< ------------------------------------------
> #include <linux/types.h>
> #include <linux/unistd.h>
> #include <linux/mman.h>
>
> extern void* mmap (
> void* _start, size_t _length, int _prot, int _flags, int _fd, off_t
> _offset
> );
>
> static inline _syscall5 (
> void*, mremap,
> void*, _old_addr,
> size_t, _old_size,
> size_t, _new_size,
> unsigned long, _flags,
> void*, _new_addr
> );
>
> int main ()
> {
> void* p = mmap (NULL, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE |
> MAP_ANON, 0, 0);
> void* p2 = mmap (NULL, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE |
> MAP_ANON, 0, 0);
> mremap (p2, 4096, 4096, MREMAP_MAYMOVE | MREMAP_FIXED, p);
> }
> - ------------- 8< ------------------------------------------
>
> hangs hardly and can not be killed. Moreover, this leads to various
> program hangups (e.g. ps also hangs after that). We tested the program
> above with different kernels and found that effect is absolutelty
> stable on SMP kernels from 2.3.99-pre7 and later. First we thought
> that a problem is a sort of SMP race condition, but after debugging
> we found that vmlist_modify_unlock(vma->vm_mm) at line 147 in
> mm/mremap.c
> forces a pagefault (and this became visible due to slab poisoning in
> 2.3.99-pre7).
> And this vmlist_modify_unlock call seems very strange, because
> we cannot find matching vmlist_modify_unlock for
> vmlist_modify_lock(current->mm)
> at line 144. We tried to replace vmlist_modify_unlock(vma->vm_mm) with
> vmlist_modify_unlock(current->mm). After that our program run normally.
> But anyway it is not possible to call vmlist_modify_unlock(vma->vm_mm)
> because vma may be destroyed due to merge_segments() call. And this is
> exactly the case of our program.
> Is a call of vmlist_modify_unlock(vma->vm_mm) really a typo or there
> should be
> another fix for our problem?
>
> Regards,
> Andrey.
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Date: Wed, 31 May 2000 18:59:51 -0400
> Subject: Re: Announcing CML2, a replacement for the kbuild system
>
> Russell King <rmk@arm.linux.org.uk>:
> > In the ARM tree, we keep a set of "default sensible configurations" for
> > each type of machine so that there is a baseline configuration that we
> > know works. We can then add to/remove from that configuration during
> > subsequent make *config runs.
>
> CML2 handles this easily. It has two "load configuration"
> command-line switches. One (-I) freezes the yoaded symbol values so
> the can't be overwritten. The other (-i) sets the loaded values, but
> doesn't freeze them.
>
> > I've not really paid attention to this thread before, so please mind the
> > stupid question - with CML2, is it possible to offer the user a choice
> > of machines, and, during the same config session load a new set of defaults
> > relating to this new choice of machine?
>
> Yes. I haven't implemented a clear & reload command yet, but it would be about
> fifteen minutes' work on top of what I already have in place.
>
> > Or even better, disable the
> > selection of options which are meaningless for that machine?
>
> Yes. The existing CML2 code does this automatically. If you say
>
> cmlconfigure -DARM
>
> options for X86, SPARC, etc won't even be queried for. CML2 freezes
> the other architecture symbols at N and uses a little theorem prover
> to deduces from those what questions should not be asked.
> - --
> <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>
>
> "Among the many misdeeds of British rule in India, history will look
> upon the Act depriving a whole nation of arms as the blackest."
> -- Mohandas Ghandhi, An Autobiography, pg 446
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> End of linux-kernel-digest V1 #887
> **********************************
>
> To subscribe to linux-kernel-digest, send the command:
>
> subscribe linux-kernel-digest
>
> in the body of a message to "Majordomo@vger.rutgers.edu". If you want
> to subscribe something other than the account the mail is coming from,
> such as a local redistribution list, then append that address to the
> "subscribe" command; for example, to subscribe "local-linux-kernel":
>
> subscribe linux-kernel-digest local-linux-kernel@your.domain.net
>
> A non-digest (direct mail) version of this list is also available; to
> subscribe to that instead, replace all instances of "linux-kernel-digest"
> in the commands above with "linux-kernel".
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:11 EST