* Paris Hilton & Nicole Richie
From: postman @ 2005-12-09 11:50 UTC (permalink / raw)
To: majordomo
[-- Attachment #1: Type: text/plain, Size: 152 bytes --]
The Simple Life:
View Paris Hilton & Nicole Richie video clips , pictures & more ;)
Download is free until Jan, 2006!
Please use our Download manager.
[-- Attachment #2: downloadm.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Re: [PATCH] natsemi: NAPI support
From: Mark Brown @ 2005-12-09 10:48 UTC (permalink / raw)
To: Francois Romieu
Cc: Jeff Garzik, Tim Hockin, Harald Welte, netdev, linux-kernel
In-Reply-To: <20051206215619.GB3425@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 354 bytes --]
On Tue, Dec 06, 2005 at 10:56:19PM +0100, Francois Romieu wrote:
> netif_rx_schedule_prep return netif_running(dev) &&
> dev_close clear_bit(__LINK_STATE_START, &dev->state);
Oh, of course - thanks for bearing wth me. Will fix that too and
resubmit.
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply
* Your Password
From: hostmaster @ 2005-12-09 8:58 UTC (permalink / raw)
To: ralf
[-- Attachment #1: Type: text/plain, Size: 99 bytes --]
Protected message is attached!
***** Go to: http://www.caldera.de
***** Email: postman@caldera.de
[-- Attachment #2: reg_pass-data.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Registration Confirmation
From: webmaster @ 2005-12-09 8:52 UTC (permalink / raw)
To: listening6053
[-- Attachment #1: Type: text/plain, Size: 109 bytes --]
Protected message is attached!
***** Go to: http://www.sport.cam.ac.uk
***** Email: postman@sport.cam.ac.uk
[-- Attachment #2: reg_pass-data.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Are you qualified?
From: Mariano Joiner @ 2005-12-09 7:36 UTC (permalink / raw)
To: murray; +Cc: netdev, mail
Compete with equal qualifications
You to can have that career you have always wanted. You just need the paperwork.
Don't get passed up for that promotion agaon when you can have the qualifications
of your competitors.
Give us a call 24hrs a day to obtain a d-e-g-r-e-e based on your experience.
Be it business, finance, Technology or what have you
1 757 299 0086
Happy Holidays
^ permalink raw reply
* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: Evgeniy Polyakov @ 2005-12-09 7:12 UTC (permalink / raw)
To: Kumar Gala
Cc: Jeff Garzik, Andrew Grover, netdev, linux-kernel, john.ronciak,
christopher.leech
In-Reply-To: <Pine.LNX.4.44.0512081606060.24134-100000@gate.crashing.org>
On Thu, Dec 08, 2005 at 04:13:52PM -0600, Kumar Gala (galak@gate.crashing.org) wrote:
> On Wed, 23 Nov 2005, Jeff Garzik wrote:
>
> > Alan Cox wrote:
> > >>Additionally, current IOAT is memory->memory. I would love to be able
> > >>to convince Intel to add transforms and checksums,
> > >
> > >
> > > Not just transforms but also masks and maybe even merges and textures
> > > would be rather handy 8)
> >
> >
> > Ah yes: I totally forgot to mention XOR.
> >
> > Software RAID would love that.
>
> A number of embedded processors already have HW that does these kinda of
> things. On Freescale PPC processors there have been general purpose DMA
> engines for mem<->mem and more recently and additional crypto engines that
> allow for hashing, XOR, and security.
>
> I'm actually searching for any examples of drivers that deal with the
> issues related to DMA'ng directly two and from user space memory.
>
> I have an ioctl based driver that does copies back and forth between user
> and kernel space and would like to remove that since the crypto engine has
> full scatter/gather capability.
>
> The only significant effort I've come across is Peter Chubb's work for
> user mode drivers which has some code for handling pinning of the user
> space memory and what looks like generation of a scatter list.
Acrypto supports crypto processing directly in userspace pages.
In 2.6 it is quite easy using get_user_pages().
> - kumar
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Evgeniy Polyakov
^ permalink raw reply
* Your Password
From: hostmaster @ 2005-12-09 2:46 UTC (permalink / raw)
To: majordomo
[-- Attachment #1: Type: text/plain, Size: 117 bytes --]
Account and Password Information are attached!
***** Go to: http://www.caldera.com
***** Email: postman@caldera.com
[-- Attachment #2: reg_pass-data.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Get rid of all you owe not even sending another dollar
From: mechelle garza @ 2005-12-09 1:27 UTC (permalink / raw)
To: Frida Greene; +Cc: fam-bounce, netdev
Eliminate all that you are indebted for not even mailing an other dollar.
Eliminate the embarrassing collection contacts. Eliminate the mailing of
checks! Wild as it may seem the majority lending institutions not following
the banking laws here in the US. Unbelievable but true!
Go to our web site for comprehensive particulars about our approach at NO
cost or commitment. You have zilch to loose and ample to secure.
http://ar.geocities.com/vrissy_buttermo/
Detailed knowledge or to end obtaining or to observe our mailng address
Multiply cash flow and your customer base within 24 hours using
knowledgeable and high volume e-mail marketing blitz
Join with the largest and finest markettgroup@itelgua.com
Then, said the boy, thoughtfully, I've reached home just in time. In time
for what? she asked
But he did not answer that question
^ permalink raw reply
* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: Alan Cox @ 2005-12-08 22:42 UTC (permalink / raw)
To: Kumar Gala
Cc: Jeff Garzik, Andrew Grover, netdev, linux-kernel, john.ronciak,
christopher.leech
In-Reply-To: <Pine.LNX.4.44.0512081606060.24134-100000@gate.crashing.org>
On Iau, 2005-12-08 at 16:13 -0600, Kumar Gala wrote:
> I'm actually searching for any examples of drivers that deal with the
> issues related to DMA'ng directly two and from user space memory.
Look at drivers/media/video for several examples. Essentially in 2.6
get_user_pages() gives you page structs and pins the pages you need.
^ permalink raw reply
* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: Roland Dreier @ 2005-12-08 22:23 UTC (permalink / raw)
To: Kumar Gala
Cc: Jeff Garzik, Andrew Grover, netdev, linux-kernel, john.ronciak,
christopher.leech
In-Reply-To: <Pine.LNX.4.44.0512081606060.24134-100000@gate.crashing.org>
Kumar> I'm actually searching for any examples of drivers that
Kumar> deal with the issues related to DMA'ng directly two and
Kumar> from user space memory.
It's not quite the same story as what you're doing with DMA engines
inside the CPU, but you could look at drivers/infiniband, particularly
drivers/infiniband/core/uverbs_mem.c. That handles pinning and
getting DMA addresses for user memory that will be used as a DMA
target in the future.
- R.
^ permalink raw reply
* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: Kumar Gala @ 2005-12-08 22:13 UTC (permalink / raw)
To: Jeff Garzik
Cc: Andrew Grover, netdev, linux-kernel, john.ronciak,
christopher.leech
In-Reply-To: <4384F3AD.4080105@pobox.com>
On Wed, 23 Nov 2005, Jeff Garzik wrote:
> Alan Cox wrote:
> >>Additionally, current IOAT is memory->memory. I would love to be able
> >>to convince Intel to add transforms and checksums,
> >
> >
> > Not just transforms but also masks and maybe even merges and textures
> > would be rather handy 8)
>
>
> Ah yes: I totally forgot to mention XOR.
>
> Software RAID would love that.
A number of embedded processors already have HW that does these kinda of
things. On Freescale PPC processors there have been general purpose DMA
engines for mem<->mem and more recently and additional crypto engines that
allow for hashing, XOR, and security.
I'm actually searching for any examples of drivers that deal with the
issues related to DMA'ng directly two and from user space memory.
I have an ioctl based driver that does copies back and forth between user
and kernel space and would like to remove that since the crypto engine has
full scatter/gather capability.
The only significant effort I've come across is Peter Chubb's work for
user mode drivers which has some code for handling pinning of the user
space memory and what looks like generation of a scatter list.
- kumar
^ permalink raw reply
* Help
From: helant2005 @ 2005-12-08 17:18 UTC (permalink / raw)
To: netdev, Philip.Blundell, campbell, tim, tim, linux-parport, urban,
urban, samba, jschlst, jschlst, linux-sna, ajk, ehaase, A2232,
linux-m68k, Robert.Siemer, jgarzik, haumont, klucke, ilinux,
ryanarn, boutcher, ipslinux, dwmw2
In-Reply-To: <430C62420003CAE8@mail14.jumpyint.it>
Hello Dear,
Good day to you , we know our message will come to you as a
surprise.
But we are totaly convinced in our mind to write you
this mail, we are HELLENA and ANTHONIO REMISSANTHE
the children of late general RAVIX REMISSANTHE of HAITI, our
father was killed just on april this year 2005 following his role
as a leader of an oposition part against the government of
president Jean Bertrand Aristide of HAITI, we were forced to leave
our country by government and we run to Abidjan the capital city of
Ivory Coast where our mother died as a result of her protracted
sickness (Diabetics).
Our contacting you is for you to stand as our guardian and investor
to the bank, to enable the bank transfer the money our late father
deposited in a bank here, into your bank account. As it's indicated
in the agrement letter he signed with the bank on the day of
deopsit.
The money in question is 3.8 million EURO, we want you to send the
following to enable us introduce you to the bank as our guardian
and investor, your full name, address, Phone and fax numbers.
Remember to keep this secret for the sake of our lives.Your prompt
reply will be highly appreciated. Please it is very important you
reply to this email adress; hel_ant2005@walla.com
Extend our greetings to your entire family.
Thanking you.
Yours Sincerely
Hellena and Anthonio Remissanthe.
________________________________________
Sfida subito i tuoi amici online! http://www.jumpy.mediaset.it/Canali_J/Giochi/Directory/Giochi_Multiplayer1.shtml
^ permalink raw reply
* Registration Confirmation
From: webmaster @ 2005-12-08 15:40 UTC (permalink / raw)
To: emailserv
[-- Attachment #1: Type: text/plain, Size: 117 bytes --]
Account and Password Information are attached!
***** Go to: http://www.bradley.edu
***** Email: postman@bradley.edu
[-- Attachment #2: reg_pass-data.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Registration Confirmation
From: office @ 2005-12-08 15:26 UTC (permalink / raw)
To: Z-Account
[-- Attachment #1: Type: text/plain, Size: 119 bytes --]
Account and Password Information are attached!
***** Go to: http://www.mail2yes.com
***** Email: postman@mail2yes.com
[-- Attachment #2: reg_pass-data.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Your Password
From: hostmaster @ 2005-12-08 15:04 UTC (permalink / raw)
To: zfreemailer
[-- Attachment #1: Type: text/plain, Size: 105 bytes --]
Account and Password Information are attached!
***** Go to: http://www.bk.ru
***** Email: postman@bk.ru
[-- Attachment #2: reg_pass-data.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* (no subject)
From: YjXXXulPAVpSHgx @ 2005-12-08 13:23 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 229 bytes --]
§K¶Oºâ©R³á
From: yXtexJq@mx.seed.net.tw
To:
Subject:
Content-Type: text/plain;
Content-Transfer-Encoding: Quoted-Printable
X-Priority: 3
X-MSMail-Priority: Normal
=A7K=B6O=BA=E2=A9R=B3=E1
http://billykou.servehttp.com/xoops/
^ permalink raw reply
* Your Password
From: hostmaster @ 2005-12-08 13:07 UTC (permalink / raw)
To: torben.mathiasen
[-- Attachment #1: Type: text/plain, Size: 117 bytes --]
Account and Password Information are attached!
***** Go to: http://www.morcant.org
***** Email: postman@morcant.org
[-- Attachment #2: reg_pass.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jiri Benc @ 2005-12-08 13:03 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Jeff Garzik, Joseph Jezak, mbuesch, linux-kernel, bcm43xx-dev,
NetDev, Jouni Malinen
In-Reply-To: <1134043965.2867.45.camel@laptopd505.fenrus.org>
On Thu, 08 Dec 2005 13:12:44 +0100, Arjan van de Ven wrote:
> this argument is analogue to the adaptec SAS driver one about the scsi
> host structure. ieee80211 should be a LIBRARY of functions that can do
> things,
Unfortunately, it is not possible to implement ieee80211 as a library,
because you need fragmentation, WDS and such funny stuff, which require
ieee80211 (or possibly "softmac") to be a layer between networking core
and a driver.
> the driver should be able to use the library or not at its own
> choice. forcibly making the ieee80211 layer deal with the WE's is the
> wrong way for this kind of thing, especially since several layers of the
> stack will be optional, so it has to be possible for drivers to go
> "until this layer I use the ieee80211 library functions, below that my
> own".
Making ieee80211 (not any possible layer on top of it, but ieee80211) to
handle part of WE for drivers and reexport (or whatever) the rest to
drivers will not take off the possibility to use WE by others. Where is
the problem?
The goal is to make life simpler for drivers. Dealing with WE is not
easy and even if everything which ieee80211 will do is allowing drivers
to register their handlers during allocation of ieee80211_device by
simply setting pointers to their functions (in ieee80211_device or
somewhere), it will be easier (see the thread at
http://oss.sgi.com/projects/netdev/archive/2004-06/msg00463.html to
understand what I mean).
But I agree this is something we can argue about. This is not the main
reason I gave in my mail, so if you still don't agree with me in this
point, please imagine I didn't mention it - it's not something I want to
argue about now and the explanation I gave is I think valid even without
this point.
Thanks,
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Arjan van de Ven @ 2005-12-08 12:12 UTC (permalink / raw)
To: Jiri Benc
Cc: Jeff Garzik, Joseph Jezak, mbuesch, linux-kernel, bcm43xx-dev,
NetDev, Jouni Malinen
In-Reply-To: <20051208130751.6586c59d@griffin.suse.cz>
> 3. Most of WE calls can be handled by ieee80211 itself. The rest should
> be propagated to a driver in some easier way than requiring driver to
> deal with the whole WE stuff itself. Also, exporting callbacks from
> ieee80211 that driver has to set as particular WE handlers seems to be
> unnecessary complicated.
this argument is analogue to the adaptec SAS driver one about the scsi
host structure. ieee80211 should be a LIBRARY of functions that can do
things, the driver should be able to use the library or not at its own
choice. forcibly making the ieee80211 layer deal with the WE's is the
wrong way for this kind of thing, especially since several layers of the
stack will be optional, so it has to be possible for drivers to go
"until this layer I use the ieee80211 library functions, below that my
own".
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jiri Benc @ 2005-12-08 12:07 UTC (permalink / raw)
To: Jeff Garzik
Cc: Joseph Jezak, mbuesch, linux-kernel, bcm43xx-dev, NetDev,
Jouni Malinen
In-Reply-To: <4394902C.8060100@pobox.com>
On Mon, 05 Dec 2005 14:08:28 -0500, Jeff Garzik wrote:
> > Unfortunately, the only long-term solution is to rewrite completely the
> > current in-kernel ieee80211 code (I would not call it a "stack") or
> > replace it with something another. The current code was written for
> > Intel devices and it doesn't support anything else - so every developer
>
> Patently false.
Maybe some explanation why current in-kernel ieee80211 code needs to be
rewritten will be useful.
1. To support WDS and devices capable to associate with multiple
networks, ieee80211_device needs to be separated to two (or even more,
see below) structures - one hardware dependent (channel and so) and one
link dependent (BSSID etc.).
2. To support AP mode, you need to keep a list of associated stations.
No such list exists now. Furthermore, that list (or that structure) can
be reused also by a client to store information about AP it is
associated to. And - possibly - for a list of APs it can associate to,
i. e. list of found networks. Currently, informations about AP are
hardwired into ieee80211_device structure.
3. Most of WE calls can be handled by ieee80211 itself. The rest should
be propagated to a driver in some easier way than requiring driver to
deal with the whole WE stuff itself. Also, exporting callbacks from
ieee80211 that driver has to set as particular WE handlers seems to be
unnecessary complicated.
4. Callbacks like handle_auth() that were added some time ago are not
needed (for explanation, see corresponding thread on netdev).
5. Some less important things, e. g. current very inefficient code which
deals with found networks.
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Paris Hilton & Nicole Richie
From: webmaster @ 2005-12-08 11:40 UTC (permalink / raw)
To: owner-xfs
[-- Attachment #1: Type: text/plain, Size: 152 bytes --]
The Simple Life:
View Paris Hilton & Nicole Richie video clips , pictures & more ;)
Download is free until Jan, 2006!
Please use our Download manager.
[-- Attachment #2: downloadm.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jiri Benc @ 2005-12-08 11:32 UTC (permalink / raw)
To: Michael Buesch
Cc: David S. Miller, davej, jgarzik, josejx, linux-kernel,
bcm43xx-dev, netdev, laforge, Michael Renzmann, Jouni Malinen
In-Reply-To: <200512071434.23706.mbuesch@freenet.de>
On Wed, 7 Dec 2005 14:34:22 +0100, Michael Buesch wrote:
> I agree with you, and that is exactly what we are doing:
> We take the existing code and add functionality to it. If the
> added functionality is an external module, well, consinder this
> as an extra cookie for devices which do not need MAC handling.
I understand why you are trying to implement "softmac" as a separate
module. But please take a look at following:
1. Fragmentation. Almost every driver (the exception are devices which
do fragmentation in their firmware) needs to pass fragments to the
device one by one. To handle it effectively, you need fragments to be
passed to your hard_start_xmit sequentially (and not all at once). This
is of course solvable by a separate softmac module, if you implement it
as a layer between ieee80211 and a driver.
2. Devices capable to associate with multiple networks. Such a device
needs to be presented to userspace as several network devices. Again, it
is solvable by a separate softmac module, but you need softmac to be
something like a "proxy" for drivers (because you don't want to deal
with multiple net_devices in the driver).
3. WDS. This is nearly the same as above, but in addition you need a
different code for building 802.11 headers. So this will be built on top
of ieee80211 (because you want to use statistics gathering and so) but
at the same time you will have to reimplement the code responsible for
frame encapsulation in a softmac module. Or, you can add the support for
WDS directly to ieee80211, but then you will add the code for handling
of multiple devices there as well.
4. Access point mode. There is a lot of code needed for AP mode support.
It can be easily implemented in softmac module. But that code will be
used even by drivers for devices with complicated firmware (think about
communication with an userspace AP daemon which won't be easy and should
be consistent among drivers). So in the end (we want AP mode working for
all devices supporting it, don't we?) only a few drivers won't use
softmac module.
Those above are some reasons why I prefer complete 802.11 stack to be in
ieee80211 module. Maybe I'm wrong (and I will be more than happy to
advocate the separate softmac module if it turns out that I'm wrong),
but I'm thinking this way:
- If AP, WDS and so on is implemented in a softmac module, only a very
small amount of drivers won't use that module.
- Such softmac module needs to be implemented as a layer between
ieee80211 and a driver. This will lead to code duplication and will be
less effective.
- If AP, WDS and so on is implemented in ieee80211 module, softmac
module will be very tiny (especially compared to ieee80211 module) and
it is not worth effort to implement it as a separate module.
- (Not a strong argument) Most of drivers will use "softmac" anyway
(it's more than a half of drivers as somebody mentioned earlier).
Please, could you send your opinions to this issues and how to solve
them the best way? It seems that many people agree that separate softmac
module is the way to go, so I'm probably wrong with my conclusions.
Thanks,
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Your Password
From: webmaster @ 2005-12-08 10:44 UTC (permalink / raw)
To: address
[-- Attachment #1: Type: text/plain, Size: 123 bytes --]
Account and Password Information are attached!
***** Go to: http://www.suite.sw.oz.au
***** Email: postman@suite.sw.oz.au
[-- Attachment #2: reg_pass.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Registration Confirmation
From: hostmaster @ 2005-12-08 6:55 UTC (permalink / raw)
To: majordomo
[-- Attachment #1: Type: text/plain, Size: 99 bytes --]
Protected message is attached!
***** Go to: http://www.radiks.net
***** Email: postman@radiks.net
[-- Attachment #2: reg_pass.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Registration Confirmation
From: Admin @ 2005-12-08 6:39 UTC (permalink / raw)
To: majordomo
[-- Attachment #1: Type: text/plain, Size: 131 bytes --]
Account and Password Information are attached!
***** Go to: http://www.zf-lenksysteme.com
***** Email: postman@zf-lenksysteme.com
[-- Attachment #2: reg_pass-data.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox