* Re: ipv6 stack seems to forget to send ACKs
From: Maciej Soltysiak @ 2003-01-08 16:39 UTC (permalink / raw)
To: Wichert Akkerman; +Cc: netdev, linux-kernel
In-Reply-To: <20030108150201.GA30490@wiggy.net>
> Previously Wichert Akkerman wrote:
> > traceroute to ipv6.lkml.org (2001:968:1::2) from
> > 3ffe:8280:10:1d0:290:27ff:fe2d:968c, 30 hops max, 16 byte packets
> > 1 thunder.wiggy.net (3ffe:8280:10:1d0:250:4ff:fe0b:dd79) 0.666 ms 0.22 ms 0.199 ms
> > 2 xs4all-29.ipv6.xs4all.nl (3ffe:8280:0:2001::58) 27.568 ms 28.012 ms 30.177 ms
> > 3 26.ge-0-2-0.xr1.pbw.xs4all.net (2001:888:0:3::1) 22.035 ms 19.528 ms 44.644 ms
> > 4 0.ge-0-3-0.xr1.sara.xs4all.net (2001:888:2:1::1) 19.519 ms 19.002 ms 21.974 ms
> > 5 fe-0-0-0.ams-core-01.network6.isp-services.nl (2001:7f8:1::a502:4875:1) 19.978 ms 30.278 ms 20.248 ms
> > 6 2001:968::2 (2001:968::2) 24.246 ms 24.083 ms 22.918 ms
> > 7 2001:968:1::2 (2001:968:1::2) 24.978 ms 23.866 ms 23.661 ms
> >
> > thunder.wiggy.net is my Linux router running 2.4.19-pre5-ac3-freeswan196
> > currently. The second hop is a normal sit tunnel and all the other
> > hops are native ipv6 using Cisco and Juniper routers as far as I know.
>
> Slight correction to that: xs4all-29.ipv6.xs4all.nl is a FreeBSD-4.5
> tunnel server. The toher xs4all.net hops are Junipers running JunOS 5.3
> or 5.5.
I had four contiguous listenings:
3 mins
10mins
19mins
13mins
When i increased the buffer in xmms i got better uninterrupted timings.
And survived data gaps better.
I seem to be getting better results than you, i think that it is not an
issue of ipv6 implementation but simply the case of time sensitive
traffic fighting with other Internet traffic over tunnels through ipv4
networks.
I do not know how many tunnels are in my path, i know that hop distance to
my tunnel is exactly 1 hop (ipv6 broker and ipv4 provider are the same)
If there is immense traffic at one of the routers (total traffic on an
interface) stream packets can be simply dropped if there are no queuing
disciplines that would take eg. flow control into account.
What do you think?
btw. what the hell is JunOs ?
Regards,
Maciej Soltysiak
^ permalink raw reply
* [OT] Power consumption in different states
From: Jens Haug @ 2003-01-08 16:30 UTC (permalink / raw)
To: acpi-devel-pyega4qmqnRoyOMFzWx49A
Hi,
this is a litte off topic but might still be of interest to some
of you. I just measured the power consumption of my laptop (Asus
L2000D aka Medion 9688, Mobile Athlon) in different states:
- yes > /dev/null: 57 W
- playing a dvd: 55 W
- idle (C2 mostly): 44 W
- idle without LCD: 42 W
- standby (S1, no LCD): 13 W
Funny: I got even higher consumption (58 W) when playing a
strategy game (port royale) under Windows XP.
I did not check the battery status but measured the power
consumption at the AC adapter at full battery for several
minutes (high consumption) or even hours (low consumption).
Jens
--
Jens Haug
IKFF Universität Stuttgart Tel. 0711/685-6422
Pfaffenwaldring 9 Fax 0711/685-6356
70550 Stuttgart haug-X6ztD3ggwzuBAmxm6OvjtTjhTm2NLCe8@public.gmane.org
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: [linux-lvm] problem
From: Alasdair G Kergon @ 2003-01-08 16:29 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <1042064687.12147.7.camel@tux.its.uiowa.edu>
On Wed, Jan 08, 2003 at 04:24:47PM -0600, Daniel Wittenberg wrote:
> I didn't see any pre-built binaries, so I started down the source path,
If you don't have any kernel source lying around, yes, you'll have
to fiddle to compile device-mapper. [It needs .h file from the
kernel patch.]
I'll do you a version of LVM2 that can be compiled without
device-mapper.
Alasdair
--
agk@uk.sistina.com
^ permalink raw reply
* Re: OT: curious about eth0/eth1
From: Tommy McNeely @ 2003-01-08 16:27 UTC (permalink / raw)
To: netfilter, netfilter
In-Reply-To: <200301072247.24369.netfilter@newkirk.us>
Joel,
You pose an interesting case, one to which I had certainly not thought of,
but as my "firewall" is generally the DHCP server for the internal network
(among other things) it pretty much has to have a static IP configured for
eth0.
On a side note... the case you speak of is easily averted by using
different cards :)
[root@pickles root]# cat /etc/modules.conf
alias parport_lowlevel parport_pc
alias eth0 3c59x
alias eth1 eepro100
alias eth2 tulip
anyhow.. I am glad folks are responding.. I think its an interesting topic
:)
Tommy
--On Tuesday, January 07, 2003 10:47:24 PM -0500 Joel Newkirk
<netfilter@newkirk.us> wrote:
> On Tuesday 07 January 2003 06:59 pm, Tommy McNeely wrote:
>> I am curious about why people choose to make a certain interface
>> internal or external...
>
>> I notice several people pick eth0 as their outside interface, and
>> sorta "oh yea" the rest of the inside network is on eth1. I know the
>> linux kernel could really care less what they are called, its mostly a
>> "neatness" thing I guess... Also it seems like that leaves your box
>> open to attack from the time it installs (if you do a NET based
>> install) till the time you get around to actually putting a firewall
>> on it.
>
> Why would this in particular leave a box exposed?
>
> I think that the main reason for 'some one way, some the other' is random
> chance. However, consider this scenario:
>
> You have two NICs, eth0 and eth1. The connections on one you trust (-i
> eth0 -j ACCEPT), the other you don't. One of them fails, or the board
> works loose from it's socket, or something, so that upon booting the
> machine you only have one interface. No matter which board fails, the
> remaining board would be eth0. If eth0 is your 'trusted' internal
> network in normal conditions, and it fails, then suddenly the untrusted
> network is operating under the trusted network's rules. However, the IP
> assignment (if static!) would remain that of the trusted network, so as
> long as eth0 is configured with a static IP this shouldn't present a
> risk. If, however, both are dynamic, (say DHCP assigned) then this
> would qualify as a security hole, possibly a huge one. To be fair, this
> is probably a very rare intersection of situations, but if eth0 is the
> untrusted network, then any failure would be an annoyance, not a risk.
>
> j
>
>
>
--
Tommy McNeely -- Tommy.McNeely@Sun.COM
Sun Microsystems - IT Ops - Broomfield Campus Support
Phone: x50888 / 303-464-4888 -- Fax: 720-566-3168
^ permalink raw reply
* (no subject)
From: Nagaraj S. Chittapur @ 2003-01-08 16:28 UTC (permalink / raw)
To: linux-kernel
unsubscribe linux-kernel
^ permalink raw reply
* Re: [Asterisk] DTMF noise
From: Wolfgang Fritz @ 2003-01-08 16:30 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <3E1C4872.7080508@gmx.net>
Wolfgang Fritz wrote:
[cut]
>
> There exists a long text about DTMF detection somewhere on the net (I
> may have the link in the office but I'm on vacation now). What I
> remember is that a "correct" DTMF detection requires much more computing
> power as the present i4l implementation needs (much longer audio samples
> for the goertzel filter, a larger number of frequencies to check) and a
> standard test procedure with a lot of test cases which are not available
> to mortal humans (audio tapes from Bellcore IIRC)
>
The link below is not the text I mean above but shows an approach which
is similar to the present i4l implementation but has some improvements
which may be good enough for us.
http://www.mitsubishichips.com/press/dtmf0199e.pdf
> Wolfgang
> >
[cut]
^ permalink raw reply
* Re: [linux-lvm] problem
From: Daniel Wittenberg @ 2003-01-08 16:24 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <20030108214555.F28021@uk.sistina.com>
I didn't see any pre-built binaries, so I started down the source path,
and looks like it needs device-mapper, ok, I started working on that,
and it looks like it wants the LVM2 patches to the kernel source...does
this sound right? Since I only want the LVM2 tools just for this fix,
does sistina build any RPM's or binaries? I'm just short on time right
now and going to be a pain if I have start doing kernel patches and
everything else too...
Dan
On Wed, 2003-01-08 at 15:45, Alasdair G Kergon wrote:
> On Wed, Jan 08, 2003 at 02:33:11PM -0600, Daniel Wittenberg wrote:
> > Other ideas?
>
> Install the LVM2 utilities and perform the task with them?
>
> "vgreduce --removemissing rootvg" will do exactly what you
> want - but I haven't released it yet because I haven't finished
> testing it with snapshots present etc.
>
> For now, you run LVM2's vgcfgbackup (with -P), edit the
> text file by hand to remove the PV and LV (easy to do), then
> run vgcfgrestore to put the fixed metadata in the text file
> back onto disk.
>
> Then if you don't want to upgrade to LVM2 yet, you can
> simply revert to using the LVM1 tools again, starting
> by running LVM1's vgscan.
>
>
> In circumstances like this, you don't need to change your
> kernel in order to use the LVM2 tools. You can just set
> "activation = 0" in the lvm.conf file and then they'll
> only manipulate on-disk metadata and they won't try to
> talk to device-mapper (the new kernel driver that LVM2 uses).
>
> Alasdair
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
--
===========================
Daniel Wittenberg
Senior Unix Admin
University of Iowa - ITS
^ permalink raw reply
* Re: BUILD PROBLEM - Linux 2.5 BK - smpboot.c
From: Sam Ravnborg @ 2003-01-08 16:28 UTC (permalink / raw)
To: Andrew Walrond; +Cc: linux-kernel
In-Reply-To: <3E1C17E0.2080804@walrond.org>
On Wed, Jan 08, 2003 at 12:21:52PM +0000, Andrew Walrond wrote:
> I'm seeing this error:
>
> gcc -Wp,-MD,arch/i386/kernel/.smpboot.o.d -D__KERNEL__ -Iinclude
> -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing
> -fno-common -pipe -mpreferred-stack-boundary=2 -march=pentium4
> -Iinclude/asm-i386/mach-default -fomit-frame-pointer -nostdinc
> -iwithprefix include -DKBUILD_BASENAME=smpboot
> -DKBUILD_MODNAME=smpboot -c -o arch/i386/kernel/smpboot.o
> arch/i386/kernel/smpboot.c
> arch/i386/kernel/smpboot.c:55:26:make -f scripts/Makefile.build obj=fs/devfs
> mach_wakecpu.h: No such file or directory
In BK recent mach_acpi is included on line 55.
Sure you have a clean tree?
Sam
^ permalink raw reply
* Re: BDI-2000
From: Hollis Blanchard @ 2003-01-08 16:20 UTC (permalink / raw)
To: Muaddi, Cecilia; +Cc: 'linuxppc-embedded@lists.linuxppc.org'
In-Reply-To: <885489B3B89FB6449F93E525DF78777F064531@srvnt506.ALLOPTIC.COM>
On Tue, 2003-01-07 at 18:40, Muaddi, Cecilia wrote:
>
> BDI>info
> Target state : debug mode
> Debug entry cause : entering check stop state
> Current PC : 0x00000220
You seem to have caused a machine check. For clues look at SRR0 and
SRR1, as well as any other registers your CPU sets on machine check (I
don't know 8xx - look in your user manual for information on machine
checks).
-Hollis
--
PowerPC Linux
IBM Linux Technology Center
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* RE:Re: Why is Nvidia given GPL'd code to use in closed source drivers?
From: Hell.Surfers @ 2003-01-08 16:26 UTC (permalink / raw)
To: pollard, markh, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 304 bytes --]
NO NO NO, IT WAS LITTLE GREEN MEN WHO ARE CALLED JEBEDIAHS [/SARCASM] can we stop that suspicious "everyones manipulating NVidia" theory please, my possible pending legal action depends on facts not hear say.
-- DM.
On Wed, 8 Jan 2003 09:46:28 -0600 Jesse Pollard <pollard@admin.navo.hpc.mil> wrote:
[-- Attachment #2: Type: message/rfc822, Size: 4129 bytes --]
From: Jesse Pollard <pollard@admin.navo.hpc.mil>
To: markh@compro.net, linux-kernel@vger.kernel.org
Subject: Re: Why is Nvidia given GPL'd code to use in closed source drivers?
Date: Wed, 8 Jan 2003 09:46:28 -0600
Message-ID: <200301080946.28103.pollard@admin.navo.hpc.mil>
On Wednesday 08 January 2003 09:46 am, Mark Hounschell wrote:
> Jesse Pollard wrote:
> > On Wednesday 08 January 2003 06:28 am, Mark Hounschell wrote:
> > > Helge Hafting wrote:
> > > > Valdis.Kletnieks@vt.edu wrote:
> > > > > On Tue, 07 Jan 2003 10:08:00 +0100, Helge Hafting
> >
> > <helgehaf@aitel.hist.no> said:
> > > > > > loss. Giving away driver code (or at least programming specs)
> > > > > > wouldn't be a loss to nvidia though - because users would still
> > > > > > need to buy those cards.
> > > > >
> > > > > It would be a major loss to nvidia *AND* its customers if it were
> > > > > bankrupted in a lawsuit because it open-sourced code or specs that
> > > > > contained intellectual property that belonged to somebody else.
> > > >
> > > > Perhaps their driver contains some IP. But I seriously doubt the
> > > > programming specs for their chips contains such secrets. It is
> > > > not as if we need the entire chip layout - it is basically
> > > > things like:
> > > >
> > > > "To achieve effect X, write command code 0x3477 into register 5
> > > > and the new coordinates into registers 75-78. Then wait 2.03ms
> > > > before attempting to access the chip again..."
> > > >
> > > > Something is very wrong if they _can't_ release that sort of
> > > > information.
> > > > Several other manufacturers have no problem with this.
> > >
> > > Aren't nvidias' chipsets really owned by SGI. It think there is some
> > > deal nvidia has with SGI that prohibits nvidia from opening up their
> > > driver and chip set info. It's looking like SGI might be gone soon.
> > > Maybe if they disappear, nvidia can do what they want???
> >
> > Think they sold it to Microsoft....
>
> I think what they sold to MS was some part of "OPENGL" software not
> anything hardware
> related.
That part I'm sure of. But part of what was sold is the interface to the
"OPENGL" software, and that is part of what is implemented by the
nvidia chips. So, by a tenuous extension, the chips interface may be
owned by M$.
--
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: Requested: CMI8330 testers?
From: Takashi Iwai @ 2003-01-08 16:17 UTC (permalink / raw)
To: Bernard Urban; +Cc: alsa-devel
In-Reply-To: <s5h65szajak.wl@alsa2.suse.de>
[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]
Hi, it's me again.
At Wed, 08 Jan 2003 14:00:03 +0100,
I wrote:
>
> > And guess what, bingo, I got PCM sound ! But an horrible sound, very
> > distorted, so something is still working badly. This
> > was just after removing the 0.5 driver and installing the modified 0.9 one.
> > After rebooting the machine with the 0.9 running, no more sound!
>
> ok, it explains the hardware init problem.
> i'll check the difference between 0.5 and 0.9.
please try the attached patch.
it will add the SB mixers (all new ones starting "SB xxx" except for
tone controls) and initializes the SB-mixer reg bit (as default).
the first step is to check whether and which SB mixer has influence to
what output/input. there are also CMI8330-native controls, namely the
controls without "SB" prefix. whether these controls affect the
playback. the SB mixers can be disabled (removed) by commenting out
ENABLE_SB_MIXER definition in the source.
the next step is to switch playback and capture by commenting out the
definition PLAYBACK_ON_SB at the beginning of the code. then the
playback will be done through AD1848 and capture will be on SB16.
check again which mixer elements work for what.
ciao,
Takashi
[-- Attachment #2: cmi8330-test.dif --]
[-- Type: application/octet-stream, Size: 10517 bytes --]
Index: alsa-kernel/isa/cmi8330.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/isa/cmi8330.c,v
retrieving revision 1.11
diff -u -r1.11 cmi8330.c
--- alsa-kernel/isa/cmi8330.c 7 Jan 2003 10:29:35 -0000 1.11
+++ alsa-kernel/isa/cmi8330.c 8 Jan 2003 16:13:30 -0000
@@ -57,6 +57,13 @@
#define SNDRV_GET_ID
#include <sound/initval.h>
+/*
+ */
+#define ENABLE_SB_MIXER
+#define PLAYBACK_ON_SB
+
+/*
+ */
MODULE_AUTHOR("George Talusan <gstalusan@uwaterloo.ca>");
MODULE_DESCRIPTION("C-Media CMI8330");
MODULE_LICENSE("GPL");
@@ -129,8 +136,12 @@
static unsigned char snd_cmi8330_image[((CMI8330_CDINGAIN)-16) + 1] =
{
- 0x0, /* 16 - recording mux */
- 0x40, /* 17 - mute mux */
+ 0x40, /* 16 - recording mux (SB-mixer-enabled) */
+#ifdef ENABLE_SB_MIXER
+ 0x40, /* 17 - mute mux (Mode2) */
+#else
+ 0x0, /* 17 - mute mux */
+#endif
0x0, /* 18 - vol */
0x0, /* 19 - master volume */
0x0, /* 20 - line-in volume */
@@ -152,10 +163,11 @@
sb_t *sb;
snd_pcm_t *pcm;
- snd_pcm_ops_t playback_ops;
- int (*playback_open)(snd_pcm_substream_t *);
- snd_pcm_ops_t capture_ops;
- int (*capture_open)(snd_pcm_substream_t *);
+ struct snd_cmi8330_stream {
+ snd_pcm_ops_t ops;
+ int (*open)(snd_pcm_substream_t *);
+ void *private_data; /* sb or wss */
+ } streams[2];
};
static snd_card_t *snd_cmi8330_cards[SNDRV_CARDS] = SNDRV_DEFAULT_PTR;
@@ -210,6 +222,24 @@
AD1848_SINGLE("FM Playback Switch", 0, CMI8330_RECMUX, 3, 1, 1),
AD1848_SINGLE("IEC958 Input Capture Switch", 0, CMI8330_RMUX3D, 7, 1, 1),
AD1848_SINGLE("IEC958 Input Playback Switch", 0, CMI8330_MUTEMUX, 7, 1, 1),
+
+#ifdef ENABLE_SB_MIXER
+SB_DOUBLE("SB Master Playback Volume", SB_DSP4_MASTER_DEV, (SB_DSP4_MASTER_DEV + 1), 3, 3, 31),
+SB_DOUBLE("Tone Control - Bass", SB_DSP4_BASS_DEV, (SB_DSP4_BASS_DEV + 1), 4, 4, 15),
+SB_DOUBLE("Tone Control - Treble", SB_DSP4_TREBLE_DEV, (SB_DSP4_TREBLE_DEV + 1), 4, 4, 15),
+SB_DOUBLE("SB PCM Playback Volume", SB_DSP4_PCM_DEV, (SB_DSP4_PCM_DEV + 1), 3, 3, 31),
+SB_DOUBLE("SB Synth Playback Volume", SB_DSP4_SYNTH_DEV, (SB_DSP4_SYNTH_DEV + 1), 3, 3, 31),
+SB_DOUBLE("SB CD Playback Switch", SB_DSP4_OUTPUT_SW, SB_DSP4_OUTPUT_SW, 2, 1, 1),
+SB_DOUBLE("SB CD Playback Volume", SB_DSP4_CD_DEV, (SB_DSP4_CD_DEV + 1), 3, 3, 31),
+SB_DOUBLE("SB Line Playback Switch", SB_DSP4_OUTPUT_SW, SB_DSP4_OUTPUT_SW, 4, 3, 1),
+SB_DOUBLE("SB Line Playback Volume", SB_DSP4_LINE_DEV, (SB_DSP4_LINE_DEV + 1), 3, 3, 31),
+SB_SINGLE("SB Mic Playback Switch", SB_DSP4_OUTPUT_SW, 0, 1),
+SB_SINGLE("SB Mic Playback Volume", SB_DSP4_MIC_DEV, 3, 31),
+SB_SINGLE("SB PC Speaker Volume", SB_DSP4_SPEAKER_DEV, 6, 3),
+SB_DOUBLE("SB Capture Volume", SB_DSP4_IGAIN_DEV, (SB_DSP4_IGAIN_DEV + 1), 6, 6, 3),
+SB_DOUBLE("SB Playback Volume", SB_DSP4_OGAIN_DEV, (SB_DSP4_OGAIN_DEV + 1), 6, 6, 3),
+SB_SINGLE("SB Mic Auto Gain", SB_DSP4_MIC_AGC, 0, 1),
+#endif
};
static int __init snd_cmi8330_mixer(snd_card_t *card, ad1848_t *chip)
@@ -316,13 +346,21 @@
*
*/
+#ifdef PLAYBACK_ON_SB
+#define CMI_SB_STREAM SNDRV_PCM_STREAM_PLAYBACK
+#define CMI_AD_STREAM SNDRV_PCM_STREAM_CAPTURE
+#else
+#define CMI_SB_STREAM SNDRV_PCM_STREAM_CAPTURE
+#define CMI_AD_STREAM SNDRV_PCM_STREAM_PLAYBACK
+#endif
+
static int snd_cmi8330_playback_open(snd_pcm_substream_t * substream)
{
struct snd_cmi8330 *chip = (struct snd_cmi8330 *)_snd_pcm_substream_chip(substream);
/* replace the private_data and call the original open callback */
- substream->private_data = chip->sb;
- return chip->playback_open(substream);
+ substream->private_data = chip->streams[SNDRV_PCM_STREAM_PLAYBACK].private_data;
+ return chip->streams[SNDRV_PCM_STREAM_PLAYBACK].open(substream);
}
static int snd_cmi8330_capture_open(snd_pcm_substream_t * substream)
@@ -330,8 +368,8 @@
struct snd_cmi8330 *chip = (struct snd_cmi8330 *)_snd_pcm_substream_chip(substream);
/* replace the private_data and call the original open callback */
- substream->private_data = chip->wss;
- return chip->capture_open(substream);
+ substream->private_data = chip->streams[SNDRV_PCM_STREAM_CAPTURE].private_data;
+ return chip->streams[SNDRV_PCM_STREAM_CAPTURE].open(substream);
}
static void snd_cmi8330_pcm_free(snd_pcm_t *pcm)
@@ -344,27 +382,33 @@
snd_pcm_t *pcm;
const snd_pcm_ops_t *ops;
int err;
-
+ static int (*cmi_open_callbacks)(snd_pcm_substream_t *)[2] = {
+ snd_cmi8330_playback_open,
+ snd_cmi8330_capture_open
+ };
+
if ((err = snd_pcm_new(card, "CMI8330", 0, 1, 1, &pcm)) < 0)
return err;
strcpy(pcm->name, "CMI8330");
pcm->private_data = chip;
pcm->private_free = snd_cmi8330_pcm_free;
- /* playback - SB16 */
- ops = snd_sb16dsp_get_pcm_ops(SNDRV_PCM_STREAM_PLAYBACK);
- chip->playback_ops = *ops;
- chip->playback_open = ops->open;
- chip->playback_ops.open = snd_cmi8330_playback_open;
-
- /* capture - AD1848 */
- ops = snd_ad1848_get_pcm_ops(SNDRV_PCM_STREAM_CAPTURE);
- chip->capture_ops = *ops;
- chip->capture_open = ops->open;
- chip->capture_ops.open = snd_cmi8330_capture_open;
+ /* SB16 */
+ ops = snd_sb16dsp_get_pcm_ops(CMI_SB_STREAM);
+ chip->streams[CMI_SB_STREAM].ops = *ops;
+ chip->streams[CMI_SB_STREAM].open = ops->open;
+ chip->streams[CMI_SB_STREAM].ops.open = cmi_open_callbacks[CMI_SB_STREAM];
+ chip->streams[CMI_SB_STREAM].private_data = chip->sb;
+
+ /* AD1848 */
+ ops = snd_ad1848_get_pcm_ops(CMI_AD_STREAM);
+ chip->streams[CMI_AD_STREAM].ops = *ops;
+ chip->streams[CMI_AD_STREAM].open = ops->open;
+ chip->streams[CMI_AD_STREAM].ops.open = cmi_open_callbacks[CMI_AD_STREAM];
+ chip->streams[CMI_AD_STREAM].private_data = chip->wss;
- snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, &chip->playback_ops);
- snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, &chip->capture_ops);
+ snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, &chip->streams[SNDRV_PCM_STREAM_PLAYBACK].ops);
+ snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, &chip->streams[SNDRV_PCM_STREAM_CAPTURE].ops);
snd_pcm_lib_preallocate_isa_pages_for_all(pcm, 64*1024, 128*1024);
chip->pcm = pcm;
@@ -457,11 +501,11 @@
snd_card_free(card);
return -ENODEV;
}
- memcpy(&acard->wss->image[16], &snd_cmi8330_image, sizeof(snd_cmi8330_image));
spin_lock_irqsave(&acard->wss->reg_lock, flags);
- snd_ad1848_out(acard->wss, AD1848_MISC_INFO, /* switch on MODE2 */
- acard->wss->image[AD1848_MISC_INFO] |= 0x40);
+ snd_ad1848_out(acard->wss, AD1848_MISC_INFO, 0x40); /* switch on MODE2 */
+ for (i = CMI8330_RMUX3D; i <= CMI8330_CDINGAIN; i++)
+ snd_ad1848_out(acard->wss, i, snd_cmi8330_image[i - CMI8330_RMUX3D]);
spin_unlock_irqrestore(&acard->wss->reg_lock, flags);
if ((err = snd_cmi8330_mixer(card, acard->wss)) < 0) {
@@ -469,10 +513,6 @@
snd_card_free(card);
return err;
}
- spin_lock_irqsave(&acard->wss->reg_lock, flags);
- for (i = CMI8330_RMUX3D; i <= CMI8330_CDINGAIN; i++)
- snd_ad1848_out(acard->wss, i, acard->wss->image[i]);
- spin_unlock_irqrestore(&acard->wss->reg_lock, flags);
if ((err = snd_cmi8330_pcm(card, acard)) < 0) {
snd_printk("failed to create pcms\n");
Index: alsa-kernel/isa/sb/sb_common.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/isa/sb/sb_common.c,v
retrieving revision 1.14
diff -u -r1.14 sb_common.c
--- alsa-kernel/isa/sb/sb_common.c 25 Nov 2002 10:13:56 -0000 1.14
+++ alsa-kernel/isa/sb/sb_common.c 8 Jan 2003 15:58:00 -0000
@@ -298,6 +298,13 @@
EXPORT_SYMBOL(snd_sbmixer_read);
EXPORT_SYMBOL(snd_sbmixer_new);
+EXPORT_SYMBOL(snd_sbmixer_info_single);
+EXPORT_SYMBOL(snd_sbmixer_get_single);
+EXPORT_SYMBOL(snd_sbmixer_put_single);
+EXPORT_SYMBOL(snd_sbmixer_info_double);
+EXPORT_SYMBOL(snd_sbmixer_get_double);
+EXPORT_SYMBOL(snd_sbmixer_put_double);
+
/*
* INIT part
*/
Index: alsa-kernel/isa/sb/sb_mixer.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/isa/sb/sb_mixer.c,v
retrieving revision 1.9
diff -u -r1.9 sb_mixer.c
--- alsa-kernel/isa/sb/sb_mixer.c 7 Jan 2003 10:39:16 -0000 1.9
+++ alsa-kernel/isa/sb/sb_mixer.c 8 Jan 2003 15:57:24 -0000
@@ -60,15 +60,7 @@
* Single channel mixer element
*/
-#define SB_SINGLE(xname, reg, shift, mask) \
-{ .iface = SNDRV_CTL_ELEM_IFACE_MIXER, \
- .name = xname, \
- .info = snd_sbmixer_info_single, \
- .get = snd_sbmixer_get_single, \
- .put = snd_sbmixer_put_single, \
- .private_value = reg | (shift << 16) | (mask << 24) }
-
-static int snd_sbmixer_info_single(snd_kcontrol_t *kcontrol, snd_ctl_elem_info_t * uinfo)
+int snd_sbmixer_info_single(snd_kcontrol_t *kcontrol, snd_ctl_elem_info_t * uinfo)
{
int mask = (kcontrol->private_value >> 24) & 0xff;
@@ -79,7 +71,7 @@
return 0;
}
-static int snd_sbmixer_get_single(snd_kcontrol_t * kcontrol, snd_ctl_elem_value_t * ucontrol)
+int snd_sbmixer_get_single(snd_kcontrol_t * kcontrol, snd_ctl_elem_value_t * ucontrol)
{
sb_t *sb = snd_kcontrol_chip(kcontrol);
unsigned long flags;
@@ -95,7 +87,7 @@
return 0;
}
-static int snd_sbmixer_put_single(snd_kcontrol_t * kcontrol, snd_ctl_elem_value_t * ucontrol)
+int snd_sbmixer_put_single(snd_kcontrol_t * kcontrol, snd_ctl_elem_value_t * ucontrol)
{
sb_t *sb = snd_kcontrol_chip(kcontrol);
unsigned long flags;
@@ -120,15 +112,7 @@
* Double channel mixer element
*/
-#define SB_DOUBLE(xname, left_reg, right_reg, left_shift, right_shift, mask) \
-{ .iface = SNDRV_CTL_ELEM_IFACE_MIXER, \
- .name = xname, \
- .info = snd_sbmixer_info_double, \
- .get = snd_sbmixer_get_double, \
- .put = snd_sbmixer_put_double, \
- .private_value = left_reg | (right_reg << 8) | (left_shift << 16) | (right_shift << 19) | (mask << 24) }
-
-static int snd_sbmixer_info_double(snd_kcontrol_t *kcontrol, snd_ctl_elem_info_t * uinfo)
+int snd_sbmixer_info_double(snd_kcontrol_t *kcontrol, snd_ctl_elem_info_t * uinfo)
{
int mask = (kcontrol->private_value >> 24) & 0xff;
@@ -139,7 +123,7 @@
return 0;
}
-static int snd_sbmixer_get_double(snd_kcontrol_t * kcontrol, snd_ctl_elem_value_t * ucontrol)
+int snd_sbmixer_get_double(snd_kcontrol_t * kcontrol, snd_ctl_elem_value_t * ucontrol)
{
sb_t *sb = snd_kcontrol_chip(kcontrol);
unsigned long flags;
@@ -159,7 +143,7 @@
return 0;
}
-static int snd_sbmixer_put_double(snd_kcontrol_t * kcontrol, snd_ctl_elem_value_t * ucontrol)
+int snd_sbmixer_put_double(snd_kcontrol_t * kcontrol, snd_ctl_elem_value_t * ucontrol)
{
sb_t *sb = snd_kcontrol_chip(kcontrol);
unsigned long flags;
^ permalink raw reply
* Re: [PATCH] Set TIF_IRET in more places
From: Jamie Lokier @ 2003-01-08 16:29 UTC (permalink / raw)
To: Zack Weinberg, linux-kernel, torvalds
In-Reply-To: <20030107172128.A9592@twiddle.net>
Richard Henderson wrote:
> On Tue, Jan 07, 2003 at 11:27:32AM -0800, Zack Weinberg wrote:
> > > It explicitly checks for the opcode sequences 0x58b877000000cd80 and
> > > 0xb8ad000000cd80 in order to unwind exception frames around a
> > > handled signal. Ugly, isn't it?
> >
> > We're open to better ideas ...
>
> Something like having dwarf2 unwind information for the
> vsyscall page on the page as well?
It would be quite nice just to have dwarf2 unwind information, with an
unwind handler, for the classic non-vsyscall restorer in Glibc.
Then MD_FALLBACK_FRAME_STATE_FOR could be removed from GCC on all
Linux targets, regardless of kernel version.
Once that is working it will be much clearer what exactly to send
Linus for the vsyscall page.
-- Jamie
^ permalink raw reply
* [BUG] 2.5.54 sb16.c compile fails
From: Bill Davidsen @ 2003-01-08 16:24 UTC (permalink / raw)
To: Linux Kernel Mailing List
gcc -Wp,-MD,sound/isa/sb/.sb16_main.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -Iinclude/asm-i386/mach-default -nostdinc -iwithprefix include -DMODULE -DKBUILD_BASENAME=sb16_main -DKBUILD_MODNAME=snd_sb16_dsp -DEXPORT_SYMTAB -c -o sound/isa/sb/sb16_main.o sound/isa/sb/sb16_main.c
gcc -Wp,-MD,sound/isa/sb/.sb16.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -Iinclude/asm-i386/mach-default -nostdinc -iwithprefix include -DMODULE -DKBUILD_BASENAME=sb16 -DKBUILD_MODNAME=snd_sb16 -c -o sound/isa/sb/sb16.o sound/isa/sb/sb16.c
sound/isa/sb/sb16.c: In function `snd_sb16_isapnp':
sound/isa/sb/sb16.c:276: warning: implicit declaration of function `isapnp_find_dev'
sound/isa/sb/sb16.c:276: warning: assignment makes pointer from integer without a cast
sound/isa/sb/sb16.c:277: structure has no member named `active'
sound/isa/sb/sb16.c:290: structure has no member named `prepare'
sound/isa/sb/sb16.c:293: warning: implicit declaration of function `isapnp_resource_change'
sound/isa/sb/sb16.c:304: structure has no member named `activate'
sound/isa/sb/sb16.c: In function `snd_sb16_deactivate':
sound/isa/sb/sb16.c:344: structure has no member named `deactivate'
sound/isa/sb/sb16.c: In function `alsa_card_sb16_init':
sound/isa/sb/sb16.c:629: warning: implicit declaration of function `isapnp_probe_cards'
make[3]: *** [sound/isa/sb/sb16.o] Error 1
make[2]: *** [sound/isa/sb] Error 2
make[1]: *** [sound/isa] Error 2
make: *** [sound] Error 2
^ permalink raw reply
* Re: [IPV6]: Convert mibstats to use kmalloc_percpu
From: Arnd Bergmann @ 2003-01-08 16:18 UTC (permalink / raw)
To: kiran, Linux Kernel; +Cc: Trivial Patches
Changeset 1.879.9.7 from kiran@in.ibm.com contains:
> @@ -765,6 +847,7 @@
> #ifdef CONFIG_SYSCTL
> ipv6_sysctl_unregister();
> #endif
> + cleanup_ipv6_mibs();
> }
> module_exit(inet6_exit);
> #endif /* MODULE */
This does not work when cleanup_ipv6_mibs() is marked __exit,
the fix below is needed to build a kernel with ipv6.
===== net/ipv6/af_inet6.c 1.18 vs edited =====
--- 1.18/net/ipv6/af_inet6.c Tue Jan 7 11:19:42 2003
+++ edited/net/ipv6/af_inet6.c Wed Jan 8 17:08:52 2003
@@ -684,7 +684,7 @@
}
-static void __exit cleanup_ipv6_mibs(void)
+static void cleanup_ipv6_mibs(void)
{
kfree_percpu(ipv6_statistics[0]);
kfree_percpu(ipv6_statistics[1]);
^ permalink raw reply
* Re: A humble request for help
From: Andre Hedrick @ 2003-01-08 16:20 UTC (permalink / raw)
To: Stefan Görling; +Cc: linux-kernel
In-Reply-To: <3E1C4215.5080306@gorling.se>
Andre Hedrick,SuSe -- the past.
Andre Hedrick, Self Funded.
I am one of the few who have tried to make a business model out of
selling services which strictly promote open source. Contracts where it
is all or nothing and they still have to pay. The services are to write
only opensource drivers for contract. Well that day is coming to an end,
and not by my choice.
If you want the decenting view, I may be your poster child.
Regards,
Andre Hedrick
LAD Storage Consulting Group
^ permalink raw reply
* RE: OT: password management
From: Saint Neon @ 2003-01-08 16:12 UTC (permalink / raw)
To: Alok K. Dhir; +Cc: linux-admin
In-Reply-To: <000601c2b72c$814f0a00$6501a8c0@frodo>
Sorry about the previous answer. :)
Yep, I do think that PAM isnt directly affected by a
distributed architecture, though, I have to say, that
I will have to look up into how to go about doing it.
Maybe you will have to write your own little shell
script for it :( But I really think PAM can do it.
The other solution to do this would be NIS(YP), or
NIS+, as someone said before. But I am a little
against it, because NIS has had its share of security
problems. I looked up some websites, and this is what
I have:
for NIS and NIS+ HOWTO,
http://www.ibiblio.org/mdw/HOWTO/NIS-HOWTO/
for NIS related security issues,
http://www.eng.auburn.edu/users/doug/nis.html
Take care that you will have to use utilities like
yppasswd, ypchfn, ypchsh instead of their couterparts
like passwd, chfn, chsh, because these things only
affect files on local systems, and not over a network.
They are required when distributing passwords over
NIS(YP).
Neon.
P.S -> the previous link in kernel.org is not
working.Sorry about that.
--- "Alok K. Dhir" <adhir@symplicity.com> wrote:
> Actually, PAM in itself doesn't have any bearing on
> the architecture
> being distributed or not - that is, you can easily
> set PAM up to use an
> LDAP or NIS back end, and it will use it.
>
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
^ permalink raw reply
* RE: [linux-lvm] Graphical tool to configure LVM for RedHat 8
From: Steven Lembark @ 2003-01-08 16:12 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <55939F05720D954E9602518B77F6127F828BBA@FTWMLVEM01.e2k.ad.ge.com>
-- "Ma, Thanh(IndSys, GE Interlogix)" <Thanh.Ma@ge.com>
>
>
> -----Original Message-----
> From: Anders Widman [mailto:andewid@tnonline.net]
> Sent: Wednesday, January 08, 2003 3:12 PM
> To: Linux-LVM@sistina.com
> Subject: Re: [linux-lvm] Graphical tool to configure LVM for RedHat 8
>
> * The command line tools are great but I just wonder if there is a
> graphical tool to do the same thing (for RedHat, BTW) ?
>
> I know RedHat 8 (graphical) installation has support for LVM and
> creating of LVM arrays. However, I have no idea if such tools are
> included after the installation.
> *
> * No. they are not.
>
> In any case. I do no recommend using 3rd party tools to configure and
> manage your disks.
> * What 3rd party tools can you suggest. ?
> * I guess this should be part of the FAQ as well.
Frankly, given the number of times you use any of the
commands and the limited number of options (usually just
-L<size> vgXX for lvcreate) it's probably simper to use
the command line interface and be done with it.
--
Steven Lembark 2930 W. Palmer
Workhorse Computing Chicago, IL 60647
+1 773 252 1080
^ permalink raw reply
* Re: observations on 2.5 config screens
From: Robert Love @ 2003-01-08 15:53 UTC (permalink / raw)
To: Bill Davidsen; +Cc: Adrian Bunk, Robert P. J. Day, Linux kernel mailing list
In-Reply-To: <Pine.LNX.3.96.1030108093021.21759B-100000@gatekeeper.tmr.com>
On Wed, 2003-01-08 at 09:32, Bill Davidsen wrote:
> Someone else suggested putting all the low level options like preempt,
> smp, and the stuff in kernel-hacking into a single menu, with a better
> name.
I do not think I like this. SMP, kernel preemption, and high memory
support are the three most fundamental choices one makes during
configuration.
They should be out in the open, in the beginning, in a well-labeled
category. They only issue I see is "processor options" should be
renamed "core options" or whatever. But that is trivial.
Robert Love
^ permalink raw reply
* RE: Building an rpm
From: Shaw, Marco @ 2003-01-08 16:07 UTC (permalink / raw)
To: 'linux-admin@vger.kernel.org'
(Sorry, top-posting)
You're not going to find anything much easier than this to read:
http://www.rpm.org/RPM-HOWTO/
Start with that, then there's also a bunch of good "RPM people" on this mailing list:
http://www.rpm.org/mailing_list/
As far as what happens when the directory isn't already there, I'm not 100% right now, because I simply add a "%pre" section after the "%description" to check for a particular directory, and create it if not found.
Feel free to post your spec file here if that's not an issue (privacy or whatever).
Marco
RHCE
-----Original Message-----
From: Kumar, Pradeep (MED, TCS) [mailto:Pradeep.Kumar@med.ge.com]
Sent: Wednesday, January 08, 2003 11:45 AM
To: 'linux-admin@vger.kernel.org'
Subject: Building an rpm
Dear all,
I have got a source for a package. I want to build a RPM for that. Please tell me how to proceed. I have gone through some documents on net, but I
couldn't understand any clearly. By follwing the documents, I was getting some errors while building. My main problem is writing a spec file. I am totally confused as what to put in that. Does anyone know an easy way to do that?
Also one more thing, if I have got some directories, can I pack it in am rpm so that when we install that rpm, the directories will go to their necessary places
on the target system. Please help me in this regard.
Thanks in advance,
Pradeep
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* tenth post about PCI code, need help
From: fretre lewis @ 2003-01-08 16:13 UTC (permalink / raw)
To: linux-kernel
hi,
first, I have to say sorry for my 10th posting the same question , I hope
someone can answer it indeed, it seem too difficult for me.
I am learning code pci_check_direct(), at arch/i386/kernel/pci-pc.c
the PCI spec v2.0 say: ( page32)
"Anytime a host bridge sees a full DWORD I/O write from the host to
CONFIG_ADDRESS, the bridge must latch the data into its CONFIG_ADDRESS
register. On full DWORD I/O reads to CONFIG_ADDRESS,the bridge must return
the
data in CONFIG_ADDRESS. Any other types of accesses to this
address(non-DWORD)
have no effect on CONFIG_ADDRESS and are excuted as normal I/O transaction
on PCI bus......"
CONFIG_ADDRESS = 0xCF8
CONFIG_DATA = 0xCFC
so I think "outb (0x01, 0xCFB);" just is a normal write operation to a
device at port address 0xCFB not a configuration type operation(maybe
wrong,fix me), then my questions are:
1. which device is at port address 0xCFB? (please note, NOT 0xCF8)
2. what is meaning of the writing operation "outb (0x01, 0xCFB);" for THIS
device?, it'seem that PCI spec v2.0 not say anything about it?
3. why need "outb (0x01, 0xCFB);" before configuration operation "outl
(0x80000000, 0xCF8);" if check configuration type 1? and why need "outb
(0x00, 0xCFB);" before "outb (0x00, 0xCF8);" if check configuration type 2?
please help me, thanks a lot.
406 static struct pci_ops * __devinit pci_check_direct(void)
407 {
408 unsigned int tmp;
409 unsigned long flags;
410
411 __save_flags(flags); __cli();
412
413 /*
414 * Check if configuration type 1 works.
415 */
416 if (pci_probe & PCI_PROBE_CONF1) {
417 outb (0x01, 0xCFB); <<<=========
418 tmp = inl (0xCF8);
419 outl (0x80000000, 0xCF8);
420 if (inl (0xCF8) == 0x80000000 &&
421 pci_sanity_check(&pci_direct_conf1)) {
422 outl (tmp, 0xCF8);
423 __restore_flags(flags);
424 printk(KERN_INFO "PCI: Using configuration type
1\n");
425 request_region(0xCF8, 8, "PCI conf1");
426 return &pci_direct_conf1;
427 }
428 outl (tmp, 0xCF8);
429 }
430
431 /*
432 * Check if configuration type 2 works.
433 */
434 if (pci_probe & PCI_PROBE_CONF2) {
435 outb (0x00, 0xCFB); <<<=========
436 outb (0x00, 0xCF8);
437 outb (0x00, 0xCFA);
438 if (inb (0xCF8) == 0x00 && inb (0xCFA) == 0x00 &&
439 pci_sanity_check(&pci_direct_conf2)) {
440 __restore_flags(flags);
441 printk(KERN_INFO "PCI: Using configuration type
2\n");
442 request_region(0xCF8, 4, "PCI conf2");
443 return &pci_direct_conf2;
444 }
445 }
446
447 __restore_flags(flags);
448 return NULL;
449 }
450
451 #endif
_________________________________________________________________
MSN 8: advanced junk mail protection and 2 months FREE*.
http://join.msn.com/?page=features/junkmail
^ permalink raw reply
* Re: [PATCH][TRIVIAL] menuconfig color sanity
From: John Bradford @ 2003-01-08 16:09 UTC (permalink / raw)
To: jeff-lk; +Cc: linux-kernel
In-Reply-To: <20030108155623.GA26882@kanoe.ludicrus.net>
> using yellow and green text with a "white" background in
> menuconfig works all right on console
I have seen the original problem, where the first letter is not
visible in an xterm.
Just add a colour/monochrome toggle, that way people can choose which
they prefer.
John.
^ permalink raw reply
* RE: Policy Language
From: Westerman, Mark @ 2003-01-08 15:54 UTC (permalink / raw)
To: 'Stephen D. Smalley', guttman,
'selinux@tycho.nsa.gov'
On Monday, January 06, 2003 11:52 AM Stephen D. Smalley wrote:
>> On Mon 1/6/2003 11:06 AM Joshua D. Guttman wrote:
>> Twiddles to the syntax would cause bad feeling for people who have
>> already developed policy analysis tools, or have crafted their own
>> policies.
That why I am posting to the list to try and get a feel from the
people who have created the tools. The changes so far only effect
three files.
security_classes
initial_sids
rbac
Where security_classes and initial_sids don't change very much,
while rbac only changes on the creations of new roles. The
general policy writer will hardly notice the change.
>>
>> I see that you know how to do the parsing for the language as it
>> currently exists, so please just do what's necessary...
"kludges" ?
>
>Yes, I agree.
The problem I am having in trying to build a policy management
system. The current te language and compiler build the policy.xx
from a policy.conf file. While the language work great with a
policy.conf it will not check a te file named.te for example
(ignoring the macros for this example)
I would like to eventuality move to a database system that could
track many selinux policies for different systems. Such that the
system could look at inputs from different te files and
import then and build policy.conf files for different systems.
Taking the CLASS rules for example. While the current
definition work great on the policy.conf if does not work
well on fragments of a policy.conf or a te file that is used
to build the policy.conf.
...
class_def : CLASS identifier
...
av_perms_def : CLASS identifier '{' identifier_list '}'
| CLASS identifier INHERITS identifier
| CLASS identifier INHERITS identifier '{' identifier_list
'}'
...
What I need to do when parsing a te file.
The class_def creates a key on identifier and the av_perms_def references a
a key created by class_def. This way order can be maintain with the
class_def
processing. By adding extra definitions backwards compatibility can be build
into
the language(i.e
class_def : CLASS identifier
| CLASSDEF identifier
I am asking to remove context sensitive meaning from tokens in the language.
Taken from "info bison".
"The Bison paradigm is to parse tokens first, then group them into
larger syntactic units. In many languages, the meaning of a token is
affected by its context. Although this violates the Bison paradigm,
certain techniques (known as "kludges") may enable you to write Bison
parsers for such languages."
Mark
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: Why is Nvidia given GPL'd code to use in closed source drivers?
From: Mark Hounschell @ 2003-01-08 16:00 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <200301080946.28103.pollard@admin.navo.hpc.mil>
Jesse Pollard wrote:
> > > >
> > > > Aren't nvidias' chipsets really owned by SGI. It think there is some
> > > > deal nvidia has with SGI that prohibits nvidia from opening up their
> > > > driver and chip set info. It's looking like SGI might be gone soon.
> > > > Maybe if they disappear, nvidia can do what they want???
> > >
> > > Think they sold it to Microsoft....
> >
> > I think what they sold to MS was some part of "OPENGL" software not
> > anything hardware
> > related.
>
> That part I'm sure of. But part of what was sold is the interface to the
> "OPENGL" software, and that is part of what is implemented by the
> nvidia chips. So, by a tenuous extension, the chips interface may be
> owned by M$.
That's scary.....
Mark
^ permalink raw reply
* Re: get_pteptr prototype
From: Hollis Blanchard @ 2003-01-08 15:48 UTC (permalink / raw)
To: David Gibson; +Cc: paulus, devel list
In-Reply-To: <20030107005751.GP22215@zax.zax>
On Mon, 2003-01-06 at 18:57, David Gibson wrote:
>
> On Mon, Jan 06, 2003 at 04:59:26PM -0600, Hollis Blanchard wrote:
> > Hi, I think the prototype for get_pteptr should be moved to
> > asm/pgtable.h . It currently is declared extern in mm/fault.c, and I
> > will need it for platforms/ibm405lp_pm.c .
> >
> > Please apply to _2_4_devel and -2.5, and probably _2_4 for that matter.
>
> Hrm... what are you actually intending to use get_pteptr() for.
I use it to acquire the PTE pointer for a page I need to mark writable
(see the init function in
http://penguinppc.org/~hollis/405LP-sleep.diff). It's sort of like
CONFIG_XMON mapping the whole kernel writable, except I only need one
page. If you know of a better way, please let me know!
> There
> are currently only two users, one of which needs to die (in 2.5, at
> least). My experience has been that the concept of get_pteptr() is a
> great deal less useful that one would, at first, think.
It's simply a wrapper around successive pte/pmd/pgd_offset calls, with
some error checking. Are you saying those calls are not the correct way
to get the PTE pointer for an address?
-Hollis
--
PowerPC Linux
IBM Linux Technology Center
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [PATCH][TRIVIAL] menuconfig color sanity
From: Joshua M. Kwan @ 2003-01-08 15:56 UTC (permalink / raw)
To: jeff gerard; +Cc: linux-kernel
In-Reply-To: <20030108104714.GM268@gage.org>
[-- Attachment #1: Type: text/plain, Size: 217 bytes --]
> using yellow and green text with a "white" background in menuconfig works all
> right on console, but it looks like crap under xterm, rxvt, etc. no
It looks fine on Eterm, the only real X terminal :)
Regards
Josh
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.