* Cooperative Linux
From: beolach @ 2004-01-27 4:56 UTC (permalink / raw)
To: linux-newbie
There was a thread on this list recently on running Linux inside windows;
to which the general consensus was that it can't really be done. However
I was reading through the weekends articles on /. <http://slashdot.org>
and found this article about a program that does exactly that:
<http://developers.slashdot.org/article.pl?sid=04/01/25/2124237&mode=thread&tid=106&tid=185&tid=190&tid=201>
(Quote from /.):
"Posted by timothy on 15:03 Sunday 25 January 2004
from the it's-real-friendly-like dept.
evilmf writes "Well... I was on my daily "relaxing" read of the LKML when I've found an interesting announce about "Cooperative Linux", in this message from Dan Aloni. It allows you to run Linux on an unmodified Win2000/XP system, just launching another app. Dan says that Cooperative Linux is 'is stable enough (on some common hardware configurations) for running a fully functional KNOPPIX/Debian system on Windows,' and provides some screenshots in the project homepage.""
Related links:
Project Homepages:
<http://www.colinux.org/>
<http://sourceforge.net/projects/colinux>
Original LKML (Linux Kernel Mailing List) Post:
<http://lkml.org/lkml/2004/1/25/96>
Slashdot Article:
<http://developers.slashdot.org/article.pl?sid=04/01/25/2124237&mode=thread&tid=106&tid=185&tid=190&tid=201>
Just thought this was of interest,
Conway S. Smith
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* RE: [PATCH] cpqarray update
From: Wiran, Francis @ 2004-01-27 4:50 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel Mailing List
Then again, maybe leaving that part alone would be ok too? i.e: keep
using pci_module_init() ... Any opinions?
thanks
-francis-
> -----Original Message-----
> From: Jeff Garzik [mailto:jgarzik@pobox.com]
> Sent: Monday, January 26, 2004 7:52 PM
> To: Wiran, Francis
> Cc: Linux Kernel Mailing List
> Subject: Re: [PATCH] cpqarray update
>
>
> Wiran, Francis wrote:
> >>You need to check the return value of pci_module_init() for errors.
> >
> > No, because the return value is determined from number of
> ctrls found,
> > and not from function return.
> >
> > int __init cpqarray_init(void)
> > {
> > ...
> > pci_module_init(&cpqarray_pci_driver);
> > cpqarray_eisa_detect();
> >
> > for(i=0;i<MAX_CTLR;i++) {
> > if(hba[i] != NULL)
> > num_ctlrs_reg++
> > }
> >
> > return (num_ctlrs_reg);
> > }
> >
> > int __init cpqarray_init_module(void)
> > {
> > if (cpqarray_init() == 0)
> > return -ENODEV;
> > return 0;
> > }
>
>
> Nope, this needs to be turned inside out. The proper PCI
> driver looks like
>
> static int __init cp_init (void)
> {
> return pci_module_init (&cp_driver);
> }
>
> static void __exit cp_exit (void)
> {
> pci_unregister_driver (&cp_driver);
> }
>
> We already handle the cases you describe. The cpqarray code -breaks-
> the API design by doing it this way.
>
> cpqarray does not fully support the pci_ids features and
> hotplug without
> this.
>
> Jeff
>
>
>
>
^ permalink raw reply
* RE: [PATCH] cpqarray update
From: Wiran, Francis @ 2004-01-27 4:48 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel Mailing List
Hmm... cpqarray supports both pci and eisa ctrls.
What would happen if there are no pci ctrl detected, but there is one
eisa ctrl detected? What do we return in cpqarray_init()? The return
code of pci_module_init is either 0 or -ENODEV. What happen if
cpqarray_init returns -ENODEV? Would the driver stay loaded? How about
0, or positive number?
thanks
-francis-
> -----Original Message-----
> From: Jeff Garzik [mailto:jgarzik@pobox.com]
> Sent: Monday, January 26, 2004 7:52 PM
> To: Wiran, Francis
> Cc: Linux Kernel Mailing List
> Subject: Re: [PATCH] cpqarray update
>
>
> Wiran, Francis wrote:
> >>You need to check the return value of pci_module_init() for errors.
> >
> > No, because the return value is determined from number of
> ctrls found,
> > and not from function return.
> >
> > int __init cpqarray_init(void)
> > {
> > ...
> > pci_module_init(&cpqarray_pci_driver);
> > cpqarray_eisa_detect();
> >
> > for(i=0;i<MAX_CTLR;i++) {
> > if(hba[i] != NULL)
> > num_ctlrs_reg++
> > }
> >
> > return (num_ctlrs_reg);
> > }
> >
> > int __init cpqarray_init_module(void)
> > {
> > if (cpqarray_init() == 0)
> > return -ENODEV;
> > return 0;
> > }
>
>
> Nope, this needs to be turned inside out. The proper PCI
> driver looks like
>
> static int __init cp_init (void)
> {
> return pci_module_init (&cp_driver);
> }
>
> static void __exit cp_exit (void)
> {
> pci_unregister_driver (&cp_driver);
> }
>
> We already handle the cases you describe. The cpqarray code -breaks-
> the API design by doing it this way.
>
> cpqarray does not fully support the pci_ids features and
> hotplug without
> this.
>
> Jeff
>
>
>
>
^ permalink raw reply
* [uml-devel] PATCH check for sys_sendfile() in port_user.c
From: Dan Shearer @ 2004-01-27 4:50 UTC (permalink / raw)
To: user-mode-linux-devel
[-- Attachment #1: Type: text/plain, Size: 613 bytes --]
Some kernels (including SuSE 2.4.20, according to
http://marc.theaimsgroup.com/?l=user-mode-linux-user&m=107437381718023&w=2)
don't have sys_sendfile, in which case the port console driver should
refuse to start up because there is no way for telnetd to get the fd.
This might not be obvious to debug.
NOTE! Not tested because it doesn't bite me! Beyond the fact that it
works on systems *with* sendfile() :-)
Should be the final word in anyone who wants to throw out commandline
parameter passing for xterm in favour of fd passing.
(And one more tiny little portability aid.)
--
Dan Shearer
dan@shearer.org
[-- Attachment #2: sendfile_patch --]
[-- Type: text/plain, Size: 380 bytes --]
--- port_user.c.orig 2004-01-24 15:48:53.000000000 +1030
+++ port_user.c 2004-01-27 15:05:40.000000000 +1030
@@ -35,6 +35,11 @@
char *end;
int port;
+ if(sys_sendfile() == -1){
+ printk("port_init : host kernel doesn't support sendfile()\n");
+ return(NULL);
+ }
+
if(*str != ':'){
printk("port_init : channel type 'port' must specify a "
"port number\n");
^ permalink raw reply
* Re: ax25 support in aprsd
From: Adi Linden @ 2004-01-27 4:44 UTC (permalink / raw)
To: John Williams; +Cc: linux-hams
In-Reply-To: <401677D8.2498.30119B@localhost>
If I understand this correct, I can connect to a filtered port on my
upstream (so to speak) and only receive the packets that pass through the
filter and still send all my traffic heard on RF to the APRS-IS?
I am still unsure about all the aprsd ports and which port(s) I need to
connect to to get my packets to the APRS-IS. In my aprsd.conf I have:
#
Server second.aprs.net 23 hub-sr
Server first.aprs.net 23 hub-sr
Server third.aprs.net 10152 hub-sr
Server fourth.aprs.net 23 hub-sr
#
This worked but I really don't know why this work. It did result in a fair
amount traffic (unnecessary traffic).
Adi
^ permalink raw reply
* Re: [LARTC] NEW imq driver
From: Roy @ 2004-01-27 4:42 UTC (permalink / raw)
To: lartc
In-Reply-To: <002a01c3e466$bb7f8700$030aa8c0@t>
Seems I was to fast to declare success,
my version is not much more stable than the original one,everything depends
on dropped packets.
This is even not imq fault afterall, can be prowed in other way also:
atempts to police outgoing trafic it will be ok until you dont touch localy
generated packets
if you try to drop them you will be sorry, because kernel will resend then
together with new ones
of cource policer will drop them too, but linux kernel keeps resending then
thus increasing rate progresively.
I noticed that with my trafic counter. internal trafic grew to enormous
levels 10X more than it can be. In reality there was almost no output at
all.
so DONT USE POLICERS ON EGRESS. on low trafic it is harmless but on 100mb/s
it probably can kill computer (not tested).
Seems imq have similar problem even if driver itself have no leaks kernel
consumes all resousces on resnending droped packets so that computer stops
responding
for now I dont have good idea how to fix it so I will try to avoid localy
generated trafic
so it will me possible to shape ingress and forward, egress will be left for
real device.
maybe later I will find how fix that
>
> It seems to capture ingress and egress traffic of all interfaces; wouldn't
> this count packets twice ?
No, ingress is for local and egress for everything so everything should be
ok (in theory)
> If the machine is doing SNAT or DNAT, what IP addresses would be seen by
> the qdisc ?
>
I made driver see the final destination address because it is more usefull
> Rubens
>
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: New NUMA scheduler and hotplug CPU
From: Martin J. Bligh @ 2004-01-27 4:38 UTC (permalink / raw)
To: Rusty Russell; +Cc: Nick Piggin, linux-kernel
In-Reply-To: <20040127024049.7B90B2C13D@lists.samba.org>
> No, actually, it wouldn't. Take it from someone who has actually
> looked at the code with an eye to doing this.
>
> Replacing static structures by dynamic ones for an architecture which
> doesn't yet exist is NOT a good idea.
Trying to force a dynamic infrastructure into the static bitmap arrays
that we have is the bad idea, IMHO. Why on earth would you want offline
CPUs in the scheduler domains? Just to make your coding easier? Sorry,
but that just doesn't cut it for me.
> Sure, if they were stupid they'd do it this way.
>
> If (when) an architecture has hotpluggable CPUs and NUMA
> characteristics, they probably will have fixed CPU *slots*, and number
> CPUs based on what slot they are in. Since the slots don't move, all
> your fancy dynamic logic will be wasted.
>
> When someone really has dynamic hotplug CPU capability with variable
> attributes, *they* can code up the dynamic hierarchy. Because *they*
> can actually test it!
The cpu numbers are now dynamically allocated tags. I don't see why
we should sacrifice that just to get cpu hotplug. Sure, it makes your
coding a little harder, but ....
>> Yup ... but you don't have to enumerate all possible positions that way.
>> See Linus' arguement re dynamic device numbers and ISCSI disks, etc.
>> Same thing applies.
>
> Crap. When all the fixed per-cpu arrays have been removed from the
> kernel, come back and talk about instantiation and location of
> arbitrary CPUS.
>
> You're way overdesigning: have you been sharing food with the AIX guys?
A cheap shot. Please, I'd expect better flaming from you.
Sorry if this makes your coding harder, but it seems clear to me that
it's the right way to go. I guess the final decision is up to Andrew,
but I really don't want to see this kind of stuff. You don't start
kthreads for every possible cpu, do you?
M.
^ permalink raw reply
* Re: iptables routing help
From: William Knop @ 2004-01-27 4:37 UTC (permalink / raw)
To: bmcdowell; +Cc: john.sullivan, netfilter
In-Reply-To: <7A3B4AA360FDEF448F3390421FC8D731014BE9CF@coxhpexg.coxhp.com>
Unfortunately, using two interfaces isn't an option, either. A friend
of mine suggested vpn, however there has to be a cleaner route.
I thought I could drop packets from the prerouting table and it would
fall into the default routing table or something like that. Surely
there has to be a way.
On Jan 26, 2004, at 11:29 AM, <bmcdowell@coxhealthplans.com> wrote:
>
> I was about to suggest the exact same thing.
>
>
> Bob
>
> -----Original Message-----
> From: netfilter-admin@lists.netfilter.org
> [mailto:netfilter-admin@lists.netfilter.org]On Behalf Of John A.
> Sullivan III
> Sent: Monday, January 26, 2004 6:06 AM
> To: William Knop
> Cc: netfilter@lists.netfilter.org
> Subject: Re: iptables routing help
>
>
> On Sun, 2004-01-25 at 13:53, William Knop wrote:
>> Okay, the problem is that we don't want to do nat (as I said in my
>> original plee for help). We need external ips on all of the machines.
>> Additionally, The ISP's DHCP server specifies it's own gateway, so I
>> can't do normal routing, without spoofing the gateway's address and
>> doing all sorts of ugly stuff (please correct me if I'm wrong).
>>
>>
>> I was under the impression one could have iptables drop a packet from
>> the prerouting or brouting table and it would go through the machine's
>> routing table, without being specified on all the lan machines as the
>> gateway.
>>
>>
>> The physical layout we have are a bunch of boxes connected to a
>> switch, and the dsl modem connected to the switch's uplink port. I
>> could have the modem jack into a firewall box, or something, however
>> the linux ethernet bridge seems to do very odd things to arps, and
>> also iptables. Would bridging be necessary?
>>
>>
>>
> <snip>
> This may not be as bad as it sounds and it my be a netfilter issue.
> Looking at the topology, I would assume that there are several devices
> on the same public subnet connect through the switch to the DSL modem
> in
> which case they should talk to each other directly on that subnet
> without sending the data across the DSL modem. But am I correct to
> understand that even though these devices share the same switch and the
> same DSL modem that they are allocated public addresses out of
> different
> IP subnets?
>
> If that is the case, the best solution is to install a second NIC into
> each device and create a separate private network as already suggested.
> Barring that, you can create a second, logical network on the same
> media. Use iproute2 to bind a second address to each of the public
> interfaces. These will all come from the same subnet and should be
> able
> to communicate with each other. Just be sure to use the secondary
> address when sending data between those devices.
>
> ip address add dev0 192.168.1.4/24
> ip address add dev0 192.168.1.5/24
> ip address add dev0 192.168.1.6/24 . . . etc.
>
> This is a bit dangerous as these devices are still publicly exposed and
> the ISP may allow traffic on RFC1918 addresses on their internal
> networks so you may want to tightly secure the devices even for traffic
> from these "private" addresses using iptables.
>
> This is the sort of set up that we use on our internal routers to
> participate in the worldwide VPN project (http://www.worldwidevpn.com).
> Good luck - John
> --
> John A. Sullivan III
> Chief Technology Officer
> Nexus Management
> +1 207-985-7880
> john.sullivan@nexusmgmt.com
> ---
> If you are interested in helping to develop a GPL enterprise class
> VPN/Firewall/Security device management console, please visit
> http://iscs.sourceforge.net
>
^ permalink raw reply
* Re: [LARTC] NEW imq driver
From: Michael Renzmann @ 2004-01-27 4:33 UTC (permalink / raw)
To: lartc
In-Reply-To: <002a01c3e466$bb7f8700$030aa8c0@t>
Hi.
Roy wrote:
> Finaly I made imq driver stable [...]
> This is completely diferent code than old imq.
May I then second the proposal to give the driver another name? How
about IMQ2, IMQng (next generation) or something like that?
Bye, Mike
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: Adding Fonts in SuSE Linux?
From: Joshua Rogers @ 2004-01-27 4:24 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <bv4ast$ppr$1@sea.gmane.org>
Dave wrote:
> How does Linux handle fonts? Can I install True Type Fonts like the
> ones I use in Win... (Sorry...) that inferior OS?
>
> Dave
If I recall, it handles it quite well (of course I could be getting my
distros confused)
I believe it has an area in either the control center or yast dedicated
to fonts. You can add or remove them from there.
(If I was anymore vague about this...... oh boy.....)
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Re: Q: Filesystem choice..
From: Charles Manning @ 2004-01-27 4:30 UTC (permalink / raw)
To: Eric W. Biederman, linux-mtd
In-Reply-To: <m3u12jr8y4.fsf@maxwell.lnxi.com>
On Monday 26 January 2004 10:53, Eric W. Biederman wrote:
> Currently I am examining the possibility of using a filesystem with
> LinuxBIOS so that I may store parameters and kernels in the flash in a
> more flexible manner.
>
> The current flash chips I am working with are NOR flash from 512KiB to
> 4MiB. And they generally have a 64KiB erase size.
>
> I have two flash blocks that are reserved for XIP code (the hw
> initialization firmware) and the rest can be used for the filesystem.
> So in the worst case I have 6 flash blocks to play with.
>
> The old papers on jffs2 would make it unacceptable as it reserves
> 5 erase blocks. And I don't know if yaffs or yaffs2 is any better.
>
> In addition boot time is important so it would be ideal if I did not
> to read every byte of the ROM chip to initialize the filesystem.
>
> Is there a filesystem that only reserves one erase block?
>
> Does it look like I need to write my own solution?
First up: Do you really need a full-blown file system? Maybe something more
along the lines of a linear file store is more suited. Maybe too just some
basic storage in binary partitions.
YAFFS is not really designed for NOR, though it has been used for NOR. For
the sizes you're talking about YAFFS would not really be a good choice
because the file headers use one "chunk" per file. THis eases garbage
collection, but swallows flash.
-- CHarles
^ permalink raw reply
* More exports for dasd in 2.6
From: Pete Zaitcev @ 2004-01-27 4:19 UTC (permalink / raw)
To: schwidefsky; +Cc: linux-kernel
Martin,
here's a little patch to add two more exports, based on my tests.
-- Pete
diff -ur -X dontdiff linux-2.6.1-1.144/drivers/s390/block/dasd.c linux-2.6.1-1.144.z1/drivers/s390/block/dasd.c
--- linux-2.6.1-1.144/drivers/s390/block/dasd.c 2004-01-21 11:22:51.000000000 -0500
+++ linux-2.6.1-1.144.z1/drivers/s390/block/dasd.c 2004-01-23 11:37:06.000000000 -0500
@@ -1982,6 +1982,7 @@
EXPORT_SYMBOL_GPL(dasd_generic_remove);
EXPORT_SYMBOL_GPL(dasd_generic_set_online);
EXPORT_SYMBOL_GPL(dasd_generic_set_offline);
+EXPORT_SYMBOL_GPL(dasd_generic_notify);
EXPORT_SYMBOL_GPL(dasd_generic_auto_online);
/*
diff -ur -X dontdiff linux-2.6.1-1.144/drivers/s390/cio/device.c linux-2.6.1-1.144.z1/drivers/s390/cio/device.c
--- linux-2.6.1-1.144/drivers/s390/cio/device.c 2004-01-21 11:22:51.000000000 -0500
+++ linux-2.6.1-1.144.z1/drivers/s390/cio/device.c 2004-01-23 11:39:53.000000000 -0500
@@ -908,3 +908,4 @@
EXPORT_SYMBOL(ccw_driver_unregister);
EXPORT_SYMBOL(get_ccwdev_by_busid);
EXPORT_SYMBOL(ccw_bus_type);
+EXPORT_SYMBOL(ccw_device_work);
^ permalink raw reply
* Re: Soundcard Matrix guidelines ?
From: Patrick Shirkey @ 2004-01-27 4:13 UTC (permalink / raw)
To: Giuliano Pochini; +Cc: Alsa-devel
In-Reply-To: <20040126193137.353b1ae9.pochini@shiny.it>
Giuliano Pochini wrote:
> Who is the maintainer of the soundcard matrix ? What is the preferred
> format for sending him updates ?
>
I am supposed to be that person :)
For now you can make additions to the relevant page and send me the
revision.
Thanks.
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org/LAU/guide/ - The Linux Audio Users guide
Http://www.djcj.org/gigs/ - Gigs guide Korea
========================================
Apparently upon the beginning of the barrage, the donkey broke
discipline and panicked, toppling the cart. At that point, the rockets
disconnected from the timer, leaving them strewn around the street.
Tethered to the now toppled cart, the donkey was unable to escape before
the arrival of U.S. troops.
United Press International
Rockets on donkeys hit major Baghdad sites
By P. MITCHELL PROTHERO
Published 11/21/2003 11:13 AM
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* radeonfb problems with 2.6.2-rc2
From: Roland Dreier @ 2004-01-27 4:12 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <Pine.LNX.4.44.0311111019210.30657-100000@home.osdl.org>
I just decided to give radeonfb a try with a 2.6 kernel (2.6.2-rc2 to
be specific). I have a Radeon 9000 Pro with two 1280x1024 LCDs
connected, one to the DVI connector and one to the CRT connector.
When it boots, I get a glimpse of the penguin logo for a moment, and
then the screen goes blank and stays blank. If I start the Radeon
XFree86 server then both screens come back to life and work fine.
I get the following in my boot log:
Linux version 2.6.2-rc2 (root@gold) (gcc version 2.95.4 20011002 (Debian prerelease)) #1 Mon Jan 26 11:41:46 PST 2004
[...]
radeonfb_pci_register BEGIN
radeonfb: ref_clk=2700, ref_div=12, xclk=27500 from BIOS
radeonfb: probed DDR SGRAM 65536k videoram
radeon_get_moninfo: bios 4 scratch = a00000a
radeonfb: panel ID string: ªhé£\x05
radeonfb: detected DFP panel size from BIOS: 1x0
radeonfb: detected DFP panel size from registers: 1280x1024
radeonfb: ATI Radeon 9000 If DDR SGRAM 64 MB
radeonfb: DVI port DFP monitor connected
radeonfb: CRT port CRT monitor connected
radeonfb_pci_register END
[...]
hStart = 680, hEnd = 960, hTotal = 1056
vStart = 482, vEnd = 501, vTotal = 522
h_total_disp = 0x4f0083 hsync_strt_wid = 0xa302a2
v_total_disp = 0x1df0209 vsync_strt_wid = 0x9301e1
post div = 0x8
fb_div = 0x59
ppll_div_3 = 0x30059
ron = 828, roff = 19684
vclk_freq = 2503, per = 703
Console: switching to colour frame buffer device 80x30
I've seen some radeonfb patches floating around, but my impression was
that 2.6.2-rc2 should work. If anyone has something for me to try,
I'd be happy to give it a spin. Otherwise I guess I'll try to figure
out what that debugging output is telling me.
Thanks,
Roland
^ permalink raw reply
* Re: [Kernel-janitors] [PATCH] drivers/ide/ide-tape.c - handle
From: Randy.Dunlap @ 2004-01-27 4:10 UTC (permalink / raw)
To: kernel-janitors
In-Reply-To: <20040122040839.GA2456@eugeneteo.net>
On Tue, 27 Jan 2004 09:04:00 +0800 Eugene Teo <eugene.teo@eugeneteo.net> wrote:
| <quote sender="Randy.Dunlap">
| > On Thu, 22 Jan 2004 12:08:39 +0800 Eugene Teo <eugene.teo@eugeneteo.net> wrote:
| >
| > | I have not compile nor test this patch. stage has to be checked for
| > | null. No trailing spaces too :)
| > |
| > | 2902: static idetape_stage_t *__idetape_kmalloc_stage (..........)
| > | [...]
| > | 2909: if ((stage = (idetape_stage_t *) kmalloc (sizeof \
| > | (idetape_stage_t),GFP_KERNEL)) = NULL)
| > | 2910: return NULL;
| > |
| > | diff -Naur -X /home/amnesia/w/dontdiff 2.6.2-rc1-orig/drivers/ide/ide-tape.c 2.6.2-rc1-fix/drivers/ide/ide-tape.c
| > | --- 2.6.2-rc1-orig/drivers/ide/ide-tape.c 2004-01-22 02:19:18.000000000 +0800
| > | +++ 2.6.2-rc1-fix/drivers/ide/ide-tape.c 2004-01-22 12:01:56.000000000 +0800
| > | @@ -3619,6 +3619,8 @@
| > | printk(KERN_INFO "ide-tape: %s: reading back %d frames from the drive's internal buffer\n", tape->name, frames);
| > | for (i = 0; i < frames; i++) {
| > | stage = __idetape_kmalloc_stage(tape, 0, 0);
| > | + if (!stage)
| > | + return;
| > | if (!first)
| > | first = stage;
| > | aux = stage->aux;
| > |
| >
| > so... what makes it OK for void function "idetape_onstream_read_back_buffer"
| > to just return at this point? It can't (or doesn't) return an error
| > AFAICT, but the calling function expected certain work to be done...
|
| this function is part of the write error recovery function that is
| meant for the unrealiable pipelined mode. after recovering from the
| internal buffer in an event of a write error, it will re-position the
| tape.
|
| Actually, I just spotted another thing that we need to fix. When we
| are in the pipelined write mode, we can't inform the user about the
| error codes (that is why it is a return void, not return error code),
| until the next task. And the next possible place to inform the user,
| is in the function "idetape_position_tape". If our read back buffer
| fails because we are unable to allocate memory for a stage, then we
| might not be able to position the tape (guess).
Yes, that's along the lines that I was concerned about.
If the kmalloc() fails and there's an early return, the state
of things might not be as they are normally expected to be,
but there's no indication of that that I can see.
| Sheese, idetape_discard_read_pipeline() should be tested to check
| whether positioning can be done but it isn't for most of the calls
| in ide-tape.c.
|
| > I guess that it could panic(), although I hate adding panics.
|
| I don't think it will panic, but it will be better if someone
| can test this.
So can anyone do some testing of these changes?
--
~Randy
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply
* Re: ax25 support in aprsd
From: John Williams @ 2004-01-27 4:08 UTC (permalink / raw)
To: linux-hams
In-Reply-To: <Pine.LNX.4.44.0401260942550.26203-100000@adibox.knet.ca>
On 26 Jan 2004 at 9:51, Adi Linden wrote:
You can connect to another igate. Depending on how this is setup
You will get all traffic or filtered traffic. You can also setup your own filters.
Have a look at these links.
http://aprs.net.au:14501/
http://www.aprs-is.net/javAPRSSrvr/javaprsfilter.htm
You just need to find a suitable igate hub (maybe someone from that part of the world can help
with a hostname).
So you can have a world feed or just local areas.
There are 2 things to consider. Your internet bandwidth (you may need to share with other
services) and what your local RF will take. If you run at 1200 bps you will want to limit this to a
maximum of 100 frames to RF per 10 minutes. This includes all local traffic.
Cheers
John
VK5ZTY
> I have a question about gating to rf, now that it has been mentioned. Is
> it possible to gate packets that were gated to TCP/IP by another specific
> igate? There is another igate about 100km away and out of RF reach.
>
> Thanks,
> Adi
>
^ permalink raw reply
* Re: [uPATCH] refuse plain ufs mount
From: Andries.Brouwer @ 2004-01-27 4:07 UTC (permalink / raw)
To: Andries.Brouwer, torvalds; +Cc: akpm, gotom, linux-kernel
From: Linus Torvalds <torvalds@osdl.org>
> But you see, it wasn't the user at all, and it wasn't a ufs filesystem.
> It is kernel probing that causes error messages. That is unwanted.
> So, your version is wrong.
Yes.
However, I think the _real_ bug is that we have reiserfs near the tail of
filesystems to try.
Can you test that alternate patch instead?
Funny how we alternate - when I choose the pure, theoretical point of view
you prefer practice, when I prefer practice you become pure.
This time you prefer practice: the list of filesystems is full of garbage
and good filesystems should be near the top.
I prefer theory: the kernel should not probe at all, so everybody who
forgets rootfstype= gets what he deserves.
Be that as it may - below a patch as I suppose you had in mind.
I don't like it very much. Ordering constraints in makefiles are bad.
Have not compiled or tested.
You can apply it I suppose, but after doing so my earlier patch is still
meaningful. Maybe you should also apply that (and the Doc update).
Andries
diff -u --recursive --new-file -X /linux/dontdiff a/fs/Makefile b/fs/Makefile
--- a/fs/Makefile 2003-12-18 03:58:57.000000000 +0100
+++ b/fs/Makefile 2004-01-27 04:51:33.000000000 +0100
@@ -48,6 +48,7 @@
obj-$(CONFIG_EXT3_FS) += ext3/ # Before ext2 so root fs can be ext3
obj-$(CONFIG_JBD) += jbd/
obj-$(CONFIG_EXT2_FS) += ext2/
+obj-$(CONFIG_REISERFS_FS) += reiserfs/
obj-$(CONFIG_CRAMFS) += cramfs/
obj-$(CONFIG_RAMFS) += ramfs/
obj-$(CONFIG_HUGETLBFS) += hugetlbfs/
@@ -84,7 +85,6 @@
obj-$(CONFIG_AUTOFS_FS) += autofs/
obj-$(CONFIG_AUTOFS4_FS) += autofs4/
obj-$(CONFIG_ADFS_FS) += adfs/
-obj-$(CONFIG_REISERFS_FS) += reiserfs/
obj-$(CONFIG_UDF_FS) += udf/
obj-$(CONFIG_SUN_OPENPROMFS) += openpromfs/
obj-$(CONFIG_JFS_FS) += jfs/
^ permalink raw reply
* Re: [2.6.1] fbdev console: can't load vga=791 and yes vga=ask!
From: Zack Winkles @ 2004-01-27 4:06 UTC (permalink / raw)
To: Xan; +Cc: linux-kernel
In-Reply-To: <200401270153.12568.DXpublica@telefonica.net>
On Tue, Jan 27, 2004 at 01:53:12AM +0100, Xan wrote:
> I don't know if it's a bug of kernel, but I can't load 2.6.1 with vga=791 in
> LILO but yes with vga=ask.
>
> In the previous version (2.6.0), I remember that I got vga=791. But perhaps I
> a personal error.
You didn't mention what driver you're using, but with vesafb simply
using the values from Documentation/fb/vesafb.txt works for me. In my
case, I pass vga=0x317.
It seems that 2.6.x is a lot more sensitive to what you pass to vga=
than was the 2.4.x series...
^ permalink raw reply
* Re: 2.6.2-rc1-mm1 oops with X
From: Mike Fedyk @ 2004-01-27 4:04 UTC (permalink / raw)
To: Glenn Johnson; +Cc: Andrew Morton, David Woodhouse, linux-kernel
In-Reply-To: <20040124043326.GB14701@gforce.johnson.home>
On Fri, Jan 23, 2004 at 10:33:27PM -0600, Glenn Johnson wrote:
> On Fri, Jan 23, 2004 at 01:56:24PM -0800, Mike Fedyk wrote:
> > > I can make it happen fairly regularly. Let me know if there is
> > > something I can do to provide more useful output.
> >
> > How, starting X?
>
> Yes.
>
> > How far does it get through, and at what point in X startup does the
> > kernel oops?
>
> I would say fairly early on but I do not know how to quantify that.
Post your log file, and show where in the log the oops occours...
^ permalink raw reply
* Mail could not be delivered
From: InterScan Notification @ 2004-01-27 4:02 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]
****** Message from InterScan Messaging Security Suite ******
Sent <<< RCPT TO:<anna-YanME59cWgQK3IM9cGFl5Q@public.gmane.org>
Received >>> 550 <anna-YanME59cWgQK3IM9cGFl5Q@public.gmane.org>... no such mailbox
Unable to deliver message to <anna-YanME59cWgQK3IM9cGFl5Q@public.gmane.org> (and other recipients in the same domain).
************************ End of message **********************
****************************************************************************************
Note: The information contained in this message may be privileged and confidential and thus protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you.
****************************************************************************************
[-- Attachment #2: Type: message/rfc822, Size: 3405 bytes --]
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2.1.1: Type: text/plain; charset="Windows-1252", Size: 2543 bytes --]
***********************
A virus (WORM_MIMAIL.R) was detected in the file (text.zip/text.txt .exe). Action taken = remove
***********-***********
$‰‹ÍsX/ÓF†™gˆâc7Eêc{—¡Dá¨Nà”«Î^«"Âv
2á~ö§Ž‹B}'&ÍœzÀ£Ý¬~áµ¹:øà}rËN;šˆu2FÁ‹b:OŒCp]/ð¨ÉB©
¡ÉÎ}ì.ÏHl}ÈÉ
„§IWZø/¯Lþ_
ðÆuLB&ë-?^ä4tVÒ¡-¨»µÇ›ìÐx†O¨%E2¶¢ž¿oLک슺áBªk1¤Î¿åV¨•Ú½ÓÑç_pˆyM¬w
ë#ZoU›_BG“ŠÌëüQùá \Lº™²&³¤dP):d)ÜŽT‡àW%J¿’Äñ/°ûá|ÓýÖ 0r_Í’óbèÕ•à£P$Þœ‘ÈDîmê²'ßÑ8^µYÞVi¡í
Š‚‰à}¹
%XÜ{™m&g
)0ÕÁx¼õÃEiËÌðÐm&:u:yæÍJÝŒWÌ\h6ûÄâEhþNWW¥!Â!v•¢{ˆÆV‘Š¨NŽ[Q5ÍíA^0\TdHyTþö«%¹Èñ(0Çîž}vDD:Ã¥PD›*OŸuŽÒ‡
Å11ú>ÖíUÙ£…,—¸ÄÃ\_œËGTí»æ
rÞôl²¤<1}Ý~UÙa¢Á:7DcÖ}
b‡Ý±8“;ò§Øð
˜Eä¾æÐàj×Õ\#ZÆœ&²Õ‡“Ýý•<ƒE¥ó˜\a§VKwx’Í™†)X“‰ŠÇQíüXKÊ®°L´ž0#t9mÝw¥Á`?:]~(Nƒ£7ø;5FÞ“|ôKÕfos$3Få†úí3š½dçæŽYV*;µlÒo
¢“›–Ò—ˆ?ø,`žNe-À¯/ *Š5”u„‚jý‹qˆµ|)Ìz–aÒùM†ž®8C¨s5Eœl¸ž®ë
´GÆ
øC¯Û!þ"PæùÄNF»Ô•å£©xãác,OH³£5o¦¬íôð1Ù0bŒcÛ™ÉuŽ¯rñÞYЂ‚
I>¿nOÑÖFöð??.efq
ÚRðz8ÜŒŽD½ÙùªÉ¶¿ûzš±ˆ t9ÎÒbs‘|ÆõÞÊbö’—Âòñ!”&#Ljþ?$cø…±º©ëFY)o›Ì4‘Íè¨ÕÞA‹4²AíàÚ¡Rn]”h„]Ïǧ8ëâ(}
ñÏ)?’f×ÞÚsö{tsKÛín÷'
÷J
{÷¶ I‰Úƒõé"ÛHºB俱_®Ó„Ü‘NsèêD|ÑO6Ñ{pÑjEE4gìpvÄÕQ‰éU5Ã}Á‰°D¨<ðßDYñä¬Ã¥}é\þ%¹¸‹,ä‚5†</¹Ä)„kS5arÂçÇOŘÚðØ
R)úrûË$üDwK‘¤MYo†AZ“ÖNc˜*L k¿C¨ÍKgáÑCÍ·!‹\I&
£dÏáFü¿Tš'LÚá%{Å71Í÷z
Bzñ~\¼ú:T\“åê>U,8·*Û-ÜD¯3ÐÄQr$W¥WkŽPø¾_§Û&Ö™w>m¥2´y™ƒ^\é"ª¢yš¹
¥{l†BË0Õ¶úhV¯ `Ù
*<ÚÁcÍaQAÜ[Oê½y¶zì`KtYÅåÖäðºâù´
ùžs ¯à”ïR‰˜â´RÁQ\lb¶îž–¾$ÞÒƒr¹à#¥ºjs‘á.g%®N¢¸0X¦`PÑ£Aî¼8µdÃEø”»’È÷²ûÑØa”ýª%q~[H]{Lèô]õ¢Þ´‡8|ùb^R.5V6„œÙ×
¦ÃâïÊ©#Y²!ù²3r’Ì·Ös*½þó†U‹¿L§•W˜X
¨›p¾…_Ì×?Ÿ…ºêª>ÃFÃð!–½§äº›[?ù\òCؽ–¥OÌ\•MîþywÏ·_¨ã\´ªBi´:¾¦l.Ö%NáHY`æ“ØcÜ™r‰gÃÈ;0`Ué´4¾Bl^¬«Ñ$.¢ë`yÍüìY%¬&3ôg…KÙ]ð
Xù°ÞOù×°®ñØå%`žªK#^V–뱋YS}ý1†Vl‡÷òææ!ÇÚœ•„
Üœ ˜`
µuíã_aþ¦yökíÄ‹wf»Š.gã¯E5§Ë"lƒãÝ$sb‡ÀªÀÛ÷ŽZ:þ:q)lÙuœÙªà¢òçkT¦í7’².¼¢½“XÉ
MKïØmÇg>±—f1±Ø‚rš0lÙ5š«{m~Ò«â¤j^ªm½G΋ôÏBù¼A¶™ã×¼½{̯Di[êŸfM÷¼†>±ÇÌóf{äøbÜÆ®&…]Èè$E)ô1œ¼_Sâ;:x¤“Š³ºüâ(OeæncìÑ4`•¢l3©O1¼O§óC[2"PD xÄμ…ã/'7>LR•|êx¯ÑhlIE[á˜ï§wéáóíÕ;ïDZ,
VÊôöÑôn¨”RP¡„)!¿¦6‚|Ýp;kðp ·üÝ>8ò7ÎNDõÐÂ-lÕÏûB‹ü7mŽÌÎ…
àÇÅ&£¼ª‡±½lêRWàX}‘kÙSò!Š#r]²Bqý–É«iNá0A)û‡_U–¬'‚®Û,„S A4“§ú~‚7G—¤§0öSH}ûónÅ>ë"æçv¾±:‰–/-§7¬ÆƬh¥]d)¯.Z…' Ób‹ò_ý÷WïnõG™i8/
¿ð÷]%|ðEƒßy0>p6#_&õ
÷•8•*¤o£EmßUšëON_êÂì8¿óþžÎÑ}Ö\›Ù÷á!u
n‹K'zº‘»°„‚nw0?uŠ½Ø£'ù͆Þá´Wcú_îlðÇ'“/†dÔl\»˜ÀT9^iÇž{êo,œ¥`áòñù{±‹¬IF‹ãL‹‹UñÑ”CU!÷wid7à½fäB³¹þIÉ~|!è¢6Ú˜N§|B|â›8É·
ÒϯÒÍt4Èù2⤛—ÍL|D¦ý^UÛ!¸·’iÆH¯ºFFóý[ÀÒ©‘¦å¼E²”ü²ëJ¼þù¶t•àÊ•Ü‚R˘†^Ivu3²ÂjÆ‚8[}O½Ñ3-ãØs|̦j°ãñ¶$WõFXYU£ßŽnT¦Lø“)¹ «íä›Ð8¦«ãÒÕtNEKú¿ÚîÓžIÄ—¶ŸÜtdçm|±RþaûR*œ!å>
e™´gëÓüQmRžÎ.ο\ÑñË 2‚7ŽÞ$PLï`˜ø7puŒüF‚!Á8û{ixfA7‰|aøíøTÎœo“6D%,Õòùé¨'îènÂ$QÈ\÷ÍdÅ)3¦n?d¬iD
?Ol‘<³¯G.¡ôM±…¸1¶^߬Ð7T^à[ˆ2âÕ
[-- Attachment #2.1.2: Type: text/plain, Size: 64 bytes --]
The attachment (text.zip) was infected with a virus and removed.
^ permalink raw reply
* Re: [LARTC] NEW imq driver
From: rubens @ 2004-01-27 3:56 UTC (permalink / raw)
To: lartc
In-Reply-To: <002a01c3e466$bb7f8700$030aa8c0@t>
> Finaly I made imq driver stable it did not crashed for all 5 hours under
> high load, soo looks stable.
> (old one was crashing after 1-5 min for me)
It seems to capture ingress and egress traffic of all interfaces; wouldn't
this count packets twice ?
If the machine is doing SNAT or DNAT, what IP addresses would be seen by
the qdisc ?
Rubens
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: sequencer filter client
From: Garett Shulman @ 2004-01-27 3:44 UTC (permalink / raw)
To: alsa-devel
In-Reply-To: <Pine.HPX.4.33n.0401261453170.24795-100000@studcom.urz.uni-halle.de>
Clemens Ladisch wrote:
>Garett Shulman wrote:
>
>
>>Hello, I am trying to create a very simple midi filter client for the
>>alsa sequencer based on aseqview-0.1.4. I have alsa 0.9.8. This code
>>shows the input and the output port in aconnect when executed. And, when
>>the raw_midi client is connected The callback does get called when I
>>play keys on my piano. However, Its as though the message is getting
>>sent back to this client and not on to the next client.
>>
>>int process_event(port_t *p, int type, snd_seq_event_t *ev, int *priate_data)
>>{
>> port_write_event(p, ev, 0);
>>}
>>
>>
>
>The event will be sent to the destination as specified in ev->dest.
>For events you have just received, the destination is your own
>client/port.
>
>Call snd_seq_ev_set_source(ev, ?) to set your source port, and call
>snd_seq_ev_set_subs(ev) to specify that the event is to be sent to all
>ports subscribed to your port.
>
>
>HTH
>Clemens
>
>
>
This does help. Thank you. -Garett
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: Might this help with SCO?
From: Bernt Hansen @ 2004-01-27 3:43 UTC (permalink / raw)
To: Joel Jaeggli; +Cc: Mike Fedyk, Linux-Kernel
In-Reply-To: <Pine.LNX.4.44.0401031518090.14343-100000@twin.uoregon.edu>
Hi,
This may or may not be useful but I've got sets of the "Linux
Developer's Resource" multi-CD sets put out by InfoMagic. The earliest
one I have is March 1995 (which is a 4-CD set). These include:
(according to the back of the box)
- Complete Linux archives from tsx-11.mit.edu and sunsite.unc.edu
- Complete GNU archive from prep.ai.mit.edu
- Debian 0.91/3
among other things including kernel sources (up to 1.2.1) etc.
The dates on some of the files in the tsx-11 archive go back to 1992.
If anyone is interested I can provide more information and extracts from
the archives.
Cheers,
Bernt.
On Sat, Jan 03, 2004 at 03:25:08PM -0800, Joel Jaeggli wrote:
> On Sat, 3 Jan 2004, Mike Fedyk wrote:
>
> > On Sat, Jan 03, 2004 at 06:03:10PM -0500, Robert L. Harris wrote:
> > >
> > > I just went digging through my old boxes for something I thought I
> > > had. Seems I have an old SLS Linux digribution, Release 0.99. The date
> > > on the postmark is June 23, 1993. It's 30 5.25 Floppies but doesn't
> > > list what kernel is on the floppies. If any of the guru's think it
> > > might be worth getting ahold of any packages on it I can see if I have a
> > > working 5.25" floppy around somewhere.
> >
> > Probably not. There are some old versions of Linux Kernel available on the
> > net. But it wouldn't it be embarrasing to show just how long some of the
> > things SCO is claiming have been in the kernel? ;)
>
> What people where looking for is source for early versions of libc. dat
> issue where the origin of the contents of ctype.h and errno.h.
>
^ permalink raw reply
* failure notice
From: MAILER-DAEMON-pb599fR3TxUuBsRpK9cBJVLXYXvW4kAk0E9HWUfgJXw @ 2004-01-27 3:43 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Hi. This is the qmail-send program at mailgate-external2.sri.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<brenda-1VPwtPCARB1BDgjK7y7TUQ@public.gmane.org>:
130.107.1.30 does not like recipient.
Remote host said: 550 5.1.1 <brenda-1VPwtPCARB1BDgjK7y7TUQ@public.gmane.org>... User unknown
Giving up on 130.107.1.30.
--- Below this line is a copy of the message.
Return-Path: <acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Received: (qmail 28510 invoked from network); 27 Jan 2004 03:43:15 -0000
Received: from localhost (HELO mailgate-external2.SRI.COM) (127.0.0.1)
by mailgate-external2.sri.com with SMTP; 27 Jan 2004 03:43:15 -0000
Received: from lists.sourceforge.net ([203.247.145.53])
by mailgate-external2.SRI.COM (SAVSMTP 3.1.2.35) with SMTP id M2004012619431331274
for <brenda-1VPwtPCARB1BDgjK7y7TUQ@public.gmane.org>; Mon, 26 Jan 2004 19:43:13 -0800
From: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
To: brenda-1VPwtPCARB1BDgjK7y7TUQ@public.gmane.org
Subject: Hi
Date: Tue, 27 Jan 2004 12:43:29 +0900
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0003_4D6F352E.E6C8D7E2"
X-Priority: 3
X-MSMail-Priority: Normal
This is a multi-part message in MIME format.
------=_NextPart_000_0003_4D6F352E.E6C8D7E2
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: 7bit
The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment.
------=_NextPart_000_0003_4D6F352E.E6C8D7E2
Content-Type: application/octet-stream;
name="doc.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="doc.zip"
UEsFBgAAAAAAAAAAAAAAAAAAAAAAAA==
------=_NextPart_000_0003_4D6F352E.E6C8D7E2--
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Request for moderated posting
From: squid-dev-help-l63656HnnUMPKjDvHGQMeg @ 2004-01-27 3:35 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
This message has been passed onto the list moderators for
approval. This is because you are not a subscriber to this
list or the related squid-users list.
If you wish to avoid this in the future, please subscribe
to the squid-dev list by sending presentation of yourself
and which areas of Squid you are interested to help with
the development of Squid to squid-dev-l63656HnnUN5HvqHVlZymw@public.gmane.org
Or alternatively if you are not really interested in helping
with the development of Squid, subscribe to the squid-users
list.
When when you have introduced yourself and your intentions
to the developers, you may send a request to subscribe on
the list to by sending an email to
squid-dev-subscribe-l63656HnnUMPKjDvHGQMeg@public.gmane.org
with no subject or body.
If you would like to subscribe an alternate email address
from the one you are posting from, send an email
to
squid-dev-help-l63656HnnUMPKjDvHGQMeg@public.gmane.org
to get help on doing this.
Please remember that squid-dev is aimed at squid developers.
If you want to contribute ideas and code, this list is for
you. If you want to track development, please use the web
archives.
Thanks!
The Squid Developers
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ 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.