status

status

[Julia Lawall]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1059 bytes --]

The following people have at least one patch accepted, or have submitted 
their first patch very recently that has not been picked up yet:

Himani Agrawal
Somya Anand
Amitoj Kaur Chawla
Ioana Ciornei
Katie Dunne
Hatice ERTÜRK
Helen Fornazier
Vatika Harlalka
Tina Johnson
Supriya Karanth
Marianne Møller Knudsen
Aya Mahfouz
Haneen Mohammed
Navya Sri Nizamkari
Darshana Padmadas
Cristina Georgiana Opriceana
Aybüke Özdemir
Vaishali Thakkar
Taiane Ramos
Ksenija Stanojevic
Yeliz Taneroğlu
Dilek Uzulmez
Ayşe Melike Yurtoğlu

If you are on this list, you should consider submitting an application.  
The deadline is March 24 at 7pm UTC, but you can update your application 
until April 1 at 7pm UTC.  In working on your application, you may find it 
useful to contact the mentors of the projects that you are interested in, 
if you have not done so already.

If you believe that you have accepted patches and are not on the above 
list, then let me know.

I counted 420 patches accepted since the beginning of the application 
period.  Great work :)

julia

Re: status

[Ioana Ciornei]

[-- Attachment #1.1: Type: text/plain, Size: 1575 bytes --]

 

On Saturday, March 21, 2015 at 7:43:53 PM UTC+2, Julia Lawall wrote:
>
> The following people have at least one patch accepted, or have submitted 
> their first patch very recently that has not been picked up yet: 
>
> Himani Agrawal 
> Somya Anand 
> Amitoj Kaur Chawla 
> Ioana Ciornei 
> Katie Dunne 
> Hatice ERTÜRK 
> Helen Fornazier 
> Vatika Harlalka 
> Tina Johnson 
> Supriya Karanth 
> Marianne Møller Knudsen 
> Aya Mahfouz 
> Haneen Mohammed 
> Navya Sri Nizamkari 
> Darshana Padmadas 
> Cristina Georgiana Opriceana 
> Aybüke Özdemir 
> Vaishali Thakkar 
> Taiane Ramos 
> Ksenija Stanojevic 
> Yeliz Taneroğlu 
> Dilek Uzulmez 
> Ayşe Melike Yurtoğlu 
>
> If you are on this list, you should consider submitting an application.   
> The deadline is March 24 at 7pm UTC, but you can update your application 
> until April 1 at 7pm UTC.  In working on your application, you may find it 
> useful to contact the mentors of the projects that you are interested in, 
> if you have not done so already. 
>
> If you believe that you have accepted patches and are not on the above 
> list, then let me know. 
>
> I counted 420 patches accepted since the beginning of the application 
> period.  Great work :) 
>
> julia


I have a question about the application process. I read that if I am 
interested in more than one project from the same organization I should 
submit only an application.
Is it true? And also, the timeline requested should be for the one I am 
most interested in?

Thanks,

Ioana 

[-- Attachment #1.2: Type: text/html, Size: 1878 bytes --]

Re: [Outreachy kernel] Re: status

[Julia Lawall]

> I have a question about the application process. I read that if I am
> interested in more than one project from the same organization I should
> submit only an application.
> Is it true? And also, the timeline requested should be for the one I am most
> interested in?

No, put all the information you have for all of the projects.

julia

Re: [Outreachy kernel] Re: status

[Ioana Ciornei]

On Tue, Mar 24, 2015 at 5:47 PM, Julia Lawall <julia.lawall@lip6.fr> wrote:
>> I have a question about the application process. I read that if I am
>> interested in more than one project from the same organization I should
>> submit only an application.
>> Is it true? And also, the timeline requested should be for the one I am most
>> interested in?
>
> No, put all the information you have for all of the projects.
>
> julia

Thanks,

Ioana

Re: [Outreachy kernel] status

[Gülşah Köse]

[-- Attachment #1: Type: text/plain, Size: 214 bytes --]

Hi Julia

This year I missed the deadline of application and I saw this mail too late
but my 11 patchs were accepted by gregkh.

Best regards

-- 
*Gülşah Köse*
*about.me <http://about.me/gulsahkose>*

[-- Attachment #2: Type: text/html, Size: 720 bytes --]

Status

[Mail Administrator]

Message could not be delivered

Re: status

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

Hi Daniel,

> While we have DHCP code in ConnMan I wouldn't recommend to port it as it
> is. Patrik reimplemented DHCP for systemd-netword using ConnMan's
> version as blueprint. That code looks much saner. Propably, it would
> make sense to carve out a library (using ELL as support library) from
> the systemd's version and make ConnMan and oFono depending on it.

Yep, I think ell is the logical place for it.  I have started putting 
together the basics for DHCP based on ideas in ConnMan/systemd and 
trying a few new ideas as well.  The approach in systemd was a bit 
heavy-handed for my taste with the use of BPFs flying everywhere.  I 
still need to see whether a simpler approach would be workable, but have 
been busy elsewhere.

Regards,
-Denis

Re: status

[Daniel Wagner]

[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]

Hi,

On 27/09/2018 18:52, Denis Kenzior wrote:>> For the
gemaltomodem/gprs-context, it is not clear how to proceed. Would
>> you kindly give some suggestion other than "these modules don't exist
>> in my world"?
> 
> I did give you a suggestion on how to proceed.  Lets get the sane ones
> supported first.  That should be mostly easy.
> 
> For the insane ones we will need to figure something else out.  For
> example, it may be that we should just have oFono initiate the DHCP
> request itself for these devices.  The driver can then control both DHCP
> and context activation status and would be able to sanely tell the core
> what is going on.  We already have DHCP code available in ConnMan that
> could be ported to oFono, or more likely finish DHCP support in ell and
> use that.

While we have DHCP code in ConnMan I wouldn't recommend to port it as it
is. Patrik reimplemented DHCP for systemd-netword using ConnMan's
version as blueprint. That code looks much saner. Propably, it would
make sense to carve out a library (using ELL as support library) from
the systemd's version and make ConnMan and oFono depending on it.

Thanks,
Daniel

Re: status

[Giacinto Cifelli]

[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]

Hi Denis,

thank you for answering on all points, now I have some feedback for
improvement.

On Thu, Sep 27, 2018 at 6:52 PM Denis Kenzior <denkenz@gmail.com> wrote:

> Hi Giacinto,
>
> > For the gemaltomodem/gprs-context, it is not clear how to proceed. Would
> > you kindly give some suggestion other than "these modules don't exist in
> > my world"?
>
> I did give you a suggestion on how to proceed.  Lets get the sane ones
> supported first.  That should be mostly easy.
>
> For the insane ones we will need to figure something else out.  For
> example, it may be that we should just have oFono initiate the DHCP
> request itself for these devices.  The driver can then control both DHCP
> and context activation status and would be able to sanely tell the core
> what is going on.  We already have DHCP code available in ConnMan that
> could be ported to oFono, or more likely finish DHCP support in ell and
> use that.
>
> Maybe there are simpler / better approaches that could be tried as well.
>   But the current proposal for these insane devices is just not going to
> work.
>

Now that you are offering some perspective, even if it is undeniably a lot
of work (and discussion), I agree on starting on the normal cases first.


Regards,
> -Denis
>

Regards,
Giacinto

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 1822 bytes --]

Re: status

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]

Hi Giacinto,

> For the gemaltomodem/gprs-context, it is not clear how to proceed. Would
> you kindly give some suggestion other than "these modules don't exist in 
> my world"?

I did give you a suggestion on how to proceed.  Lets get the sane ones 
supported first.  That should be mostly easy.

For the insane ones we will need to figure something else out.  For 
example, it may be that we should just have oFono initiate the DHCP 
request itself for these devices.  The driver can then control both DHCP 
and context activation status and would be able to sanely tell the core 
what is going on.  We already have DHCP code available in ConnMan that 
could be ported to oFono, or more likely finish DHCP support in ell and 
use that.

Maybe there are simpler / better approaches that could be tried as well. 
  But the current proposal for these insane devices is just not going to 
work.

Regards,
-Denis

status

[Giacinto Cifelli]

[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]

Hi Denis, Marcel,

so far you have accepted minor adjustments here and there, rejected the
gemaltomodem/location-reporting, gave very useful comments on the
gemaltomodem/voicecall atom. On top of it, I have some homework to find out
which call of the option linux kernel is blocking for 30/60 seconds.

For the gemaltomodem/gprs-context, it is not clear how to proceed. Would
you kindly give some suggestion other than "these modules don't exist in my
world"?

Also, I would like to know where do we stand with the following, on which I
have seen no commments at all:
from the 23.09.2018:
  atmodem/gprs: added LTE and NR indicators - absolutely needed to handle
IMC stacks
  atmodem/gprs: added autoattach handling - needed to avoid ofono
self-destruction
  atmodem/gprs: initial Gemalto vendor - on top of the previous ones

from the 25.09.2018:
  4 patches for the OFONO_GPRS_AUTH_METHOD_NONE.
Here I need to know if you are willing to do it or not. The initial answer
was permissive, but then I have the impression you changed your mind.

Thank you,
best regards,
Giacinto

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 1336 bytes --]

Status

[Automatic Email Delivery Software]

The original message was received at Mon, 21 May 2018 11:20:19 +0800
from lists.01.org [80.196.162.190]

----- The following addresses had permanent fatal errors -----
<linux-nvdimm@lists.01.org>

----- Transcript of session follows -----
  while talking to lists.01.org.:
>>> MAIL From:"Automatic Email Delivery Software" <MAILER-DAEMON@lists.01.org>
<<< 501 "Automatic Email Delivery Software" <MAILER-DAEMON@lists.01.org>... Refused



_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Status

[Automatic Email Delivery Software]

The original message was received at Mon, 21 May 2018 11:20:19 +0800
from lists.01.org [80.196.162.190]

----- The following addresses had permanent fatal errors -----
<linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org>

----- Transcript of session follows -----
  while talking to lists.01.org.:
>>> MAIL From:"Automatic Email Delivery Software" <MAILER-DAEMON-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org>
<<< 501 "Automatic Email Delivery Software" <MAILER-DAEMON-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org>... Refused

status

[The Post Office]

The original message was received at Fri, 25 Aug 2017 20:37:48 +0800
from lists.01.org [190.49.126.124]

----- The following addresses had permanent fatal errors -----
<linux-nvdimm@lists.01.org>



_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

status

[The Post Office]

The original message was received at Fri, 25 Aug 2017 20:37:48 +0800
from lists.01.org [190.49.126.124]

----- The following addresses had permanent fatal errors -----
<linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org>

Status

[Bounced mail]

The original message was received at Wed, 23 Aug 2017 14:05:47 +0800
from lists.01.org [186.54.6.33]

----- The following addresses had permanent fatal errors -----
<linux-nvdimm@lists.01.org>



_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Status

[Bounced mail]

The original message was received at Wed, 23 Aug 2017 14:05:47 +0800
from lists.01.org [186.54.6.33]

----- The following addresses had permanent fatal errors -----
<linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org>

status

[Julia Lawall]

Hello,

I have sent messages to everyone who has more accepted patches now than
the last time I sent such messages.  If you didn't hear from me and think
you should have, please let me know.

julia

status

[Julia Lawall]

Hello,

I have written to each applicant with respect to their number of accepted
patches (typically as of yesterday).  If you didn't hear from me, please
let me know.

thanks,
julia

status

[Julia Lawall]

Hello,

Thanks everyone for all of the patches submitted so far!

The following people already have a good number of accepted patches and
can work on the small tasks:

Sayli Karnik
Eva Rachel Retuya
Sandhya Bankar
Rehas Sachdeva
Anchal Jain
Bhumika Goyal
Gargi Sharma

The following people should still work on cleanup patches, but should
avoid cleanups in whitespace and comments:

Katie Dunne
Georgiana Rodica Chelu
Juliana Rodrigues
Namrata A Shettar

Let me know if you think you should be on one or the other of these lists,
but don't see your name.

thanks,
julia

status

[Returned mail]

The original message was received at Fri, 5 Aug 2016 13:45:54 +0530
from [145.215.30.154]

----- The following addresses had permanent fatal errors -----
linux-nvdimm@lists.01.org



_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

status

[Returned mail]

[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]

Spam detection software, running on the system "blaine.gmane.org",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  The original message was received at Fri, 5 Aug 2016 13:45:54
   +0530 from [145.215.30.154] ----- The following addresses had permanent fatal
   errors ----- linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Linux-nvdimm mailing list Linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org
   https://lists.01.org/mailman/listinfo/linux-nvdimm [...] 

Content analysis details:   (8.4 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was blocked.
                            See
                            http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                             for more information.
                            [URIs: 01.org]
-0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at http://www.dnswl.org/, no
                            trust
                            [198.145.21.10 listed in list.dnswl.org]
 0.6 RCVD_IN_SORBS_WEB      RBL: SORBS: sender is an abusable web server
                            [103.204.166.162 listed in dnsbl.sorbs.net]
-0.6 RP_MATCHES_RCVD        Envelope sender domain matches handover relay domain
 2.2 AXB_XMAILER_MIMEOLE_OL_024C2 No description available.
 3.4 MSOE_MID_WRONG_CASE    No description available.
 2.8 FORGED_MUA_OUTLOOK     Forged mail pretending to be from MS Outlook



[-- Attachment #2: original message before SpamAssassin --]
[-- Type: message/rfc822, Size: 2689 bytes --]

From: "Returned mail" <postmaster-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org>
To: linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org
Subject: status
Date: Fri, 5 Aug 2016 13:45:54 +0530
Message-ID: <20160805081603.838901A1DFC-y27Ovi1pjclAfugRpC6u6w@public.gmane.org>

The original message was received at Fri, 5 Aug 2016 13:45:54 +0530
from [145.215.30.154]

----- The following addresses had permanent fatal errors -----
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org



_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

status

[Julia Lawall]

Hello,

I believe that I have sent everyone who has submitted patches in this
round a comment on their current status.  If you have not heard from me,
please let me know.

thanks,
julia

status

[Julia Lawall]

Hello,

I have noted that you have 12 patches accepted.  This is a great start, so
keep up the good work.  At this point, I would avoid whitespace patches
completely, and start to work on more interesting things, like you have
already done.  You may also want to think about which specific projects
you might like to work on, and discuss with the respective mentor what you
could do.

julia

Re: Status

[Jens Axboe]

On 2012-04-12 17:16, Martin Steigerwald wrote:
> Am Donnerstag, 12. April 2012 schrieb Jens Axboe:
>> Hi,
> 
> Hi!
> 
>> In case you didn't notice, fio-2.0.7 was tagged yesterday. After
>> tagging 2.0.7, I pulled in a few changes from the gfio branch
>> that you might like to know about.
> 
> Regarding packaging fio.
> 
> Do you think fio 2.0.7 is stable enough for packaging?
> 
> If so, I�d schedule updating the Debian package to it.
> 
> Initially you recommended to stick with 1.x.

Yes, you can package 2.x now, it's stable.

-- 
Jens Axboe

Re: Status

[Martin Steigerwald]

Am Donnerstag, 12. April 2012 schrieb Jens Axboe:
> Hi,

Hi!

> In case you didn't notice, fio-2.0.7 was tagged yesterday. After
> tagging 2.0.7, I pulled in a few changes from the gfio branch
> that you might like to know about.

Regarding packaging fio.

Do you think fio 2.0.7 is stable enough for packaging?

If so, I´d schedule updating the Debian package to it.

Initially you recommended to stick with 1.x.

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Status

[Jens Axboe]

Hi,

In case you didn't notice, fio-2.0.7 was tagged yesterday. After
tagging 2.0.7, I pulled in a few changes from the gfio branch
that you might like to know about.

One is the ability to dump the normal end output while fio keeps
running. This is useful for long running jobs, where you might
like to know what's going on outside of just the IOPS and throughput
numbers etc. If you send the master fio process a USR1 signal,
it'll display the normal end of job output now and continue doing
it's thing. It's done outside of the normal IO paths and by a
separate thread off the signal, so impact on the actual job should
be minimal.

Another change is the inclusion of parts of the git sha in the
fio version output. It used to just be fio-2.0.6 for any version
between 2.0.6 and 2.0.7, but now it also includes the current
git sha:

axboe@nelson:/home/axboe/git/fio $ ./fio --version
fio-2.0.7-5-g8423b

Since some people have scripts that parse the output, I thought
I'd mention it here as well.

Outside of the master branch, gfio has made some progress. It's now
good enough to run existing jobs, either locally or on a remote
machine. There's still a bunch of things missing, like a better
results manager, ability to print output, and actual working support
for editing a job either from scratch or from an existing job file.
If you are interested in this gtk2/3 frontend for fio, I'd
encourage you to give it a shot. It's mostly for developers at this
point, but any sort of input would be useful.

-- 
Jens Axboe

Re: status

[T + J Williams]

There are a few of us left :-)

On Wed, 2010-06-23 at 08:33 -0700, Bob Smits wrote:
> > What's the status of linux-hams? Anyone left?
> > 
> > 
> > Folkert van Heusden
> > 
> 
> Some of us are still here, lurking.
> 
> I came looking for linux implementations for packet.

73

Ted - wa0eir
http://wa0eir.ham.org

There are 10 types of people in this world:
those who understand binary, and those who don't.

Re: status

[Bob Smits]

On June 22, 2010 12:46:16 pm folkert wrote:
> Hi,
> 
> What's the status of linux-hams? Anyone left?
> 
> 
> Folkert van Heusden
> 

Some of us are still here, lurking.

I came looking for linux implementations for packet.

-- 
Robert (Bob) Smits <bob@rsmits.ca>
                                                              __|    
                                                           _/.   | \   
(VE7HS)                CQ CQ CQ !!!    <      (0) | 
                                                     _   /__      |  
Ladysmith BC                              (  )<______/  
                                                      \ \/            \__

Re: status

[Curt, WE7U]

On Tue, 22 Jun 2010, folkert wrote:

> What's the status of linux-hams? Anyone left?

There's been some activity on the list this month.  More than 100
messages so far this year.

-- 
Curt, WE7U.                         <http://www.eskimo.com/~archer>
    APRS:  Where it's at!                    <http://www.xastir.org>
   Lotto:  A tax on people who are bad at math. - unknown
Windows:  Microsoft's tax on computer illiterates. - WE7U.
The world DOES revolve around me:  I picked the coordinate system!"

status

[folkert]

Hi,

What's the status of linux-hams? Anyone left?


Folkert van Heusden

-- 
Nagios users: http://vanheusden.com/java/CoffeeSaint/ check it out
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

Status

[Returned mail]

[-- Attachment #1: Type: text/plain, Size: 181 bytes --]

This message has been processed by Symantec AntiVirus.

transcript.exe was infected with the malicious virus W32.Mydoom!gen and has been deleted because the file cannot be cleaned.

[-- Attachment #2: Type: message/rfc822, Size: 1738 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 353 bytes --]

Dear user of www.linux.org.uk,

Your account was used to send a large amount of unsolicited e-mail messages during this week.
Obviously, your computer was infected and now contains a trojan proxy server.

We recommend that you follow instructions in the attachment in order to keep your computer safe.

Best regards,
The www.linux.org.uk support team.


[-- Attachment #2.1.2: transcript.zip --]
[-- Type: application/octet-stream, Size: 22 bytes --]

[-- Attachment #3: Type: text/plain, Size: 147 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@lists.linux.org.uk
http://lists.linux.org.uk/mailman/listinfo/cpufreq

Re: Status

[Heinz-Juergen Oertel]

Hallo,

Leider bin ich bis 26.11 nicht erreichbar.
Senden Sie Ihre Email in dringenden Faellen zu mailto:service-pJ9TYRvN+WE@public.gmane.org +49 (345) 777 55 0

Hello,
I received your mail,
Unfortunately I am not available until November 26.
I will read your Email when I'm back at office
(or accasionally.) Your Mail will not be forewarded.

For important things mail to
mailto:service-pJ9TYRvN+WE@public.gmane.org or call +49 (345) 777 55 0








-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click

status

[Automatic Email Delivery Software]

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

The message was undeliverable due to the following reason:

Your message was not delivered because the destination server was
not reachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.

Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.

Your message could not be delivered within 1 days:
Server 210.236.48.28 is not responding.

The following recipients did not receive this message:
<linux-kernel@vger.kernel.org>

Please reply to postmaster@vger.kernel.org
if you feel this message to be in error.


[-- Attachment #2: document.bat --]
[-- Type: application/octet-stream, Size: 28864 bytes --]

Status

[nama-BTnu/qeCbZN4Eiagz67IpQ]

[-- Attachment #1: Type: text/plain, Size: 462 bytes --]

------------------  Virus Warning Message (on the network)

Found virus WORM_MYTOB.AK in file doc.htm                                                                      .pif (in doc.zip)
The file doc.zip is moved to /var/quarantine/virus/virOFT36jZiY.

This is a machine-generated message, please do not reply via e-mail. If you have questions, please contact the Lucent Help Desk at +1 888 300 0770.

---------------------------------------------------------

[-- Attachment #2: Type: text/plain, Size: 83 bytes --]

The message contains Unicode characters and has been sent as a binary attachment.


[-- Attachment #3: Type: text/plain, Size: 177 bytes --]


------------------  Virus Warning Message (on the network)

doc.zip is removed from here because it contains a virus.

---------------------------------------------------------

Re: Status

[administracion-newprint]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

El correo al cual a enviado este eMail no existe, para contactar con nosotros por favor envie sus correos a alguna de las siguientes direcciones.

administración@in-out.es 	Administracion Grupo IN-out.

comercial@in-out.es		Dpto. Comercial Grupo IN-out.

pedidos@in-out.es		Pedidos Grupo IN-out.

grafismo@in-out.es		Dpto. diseño Grupo IN-out


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Status

[alhartman6]

[-- Attachment #1: Type: text/plain, Size: 714 bytes --]

This message was not delivered due to the following reason:

Your message was not delivered because the destination server was
not reachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.

Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.

Your message was not delivered within 7 days:
Host 135.118.116.219 is not responding.

The following recipients could not receive this message:
<linux-kernel@vger.kernel.org>

Please reply to postmaster@vger.kernel.org
if you feel this message to be in error.


[-- Attachment #2: readme.zip --]
[-- Type: application/octet-stream, Size: 28982 bytes --]

STATUS

[y.petrova-+M9NW37X/RNal66kLdaElA]

[-- Attachment #1: Type: text/plain, Size: 101 bytes --]

The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment.


[-- Attachment #2: DELETED0.TXT --]
[-- Type: text/plain, Size: 128 bytes --]

File attachment: message.scr
A file attached to this email was removed
because it was infected with a virus.

W32.Novarg.A@mm

Re: status

[Antonino Daplas]

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

On Sat, 2002-11-23 at 00:04, James Simmons wrote:
> 

> > 1. optimized putcs to speed up scrolling by 2-3x.  (it's a small patch
> > but it already outperforms fb-2.4 especially at high color depths).
> > Compared with the previous patch I submitted, this change is
> > non-intrusive, so no other changes are required.
> >
> > 2. vga16fb imageblit that supports drawing of the penguin (vga-4-planes
> > only)
> > 
> > 3. logo drawing for directcolor visuals.
> 
> Please send me those patches ASAP!!! I will linclude them right away.
>  
Okay.  Instead of patches, I'll just attach a file with the targeted
functions which you can choose to cut and paste or modify as you see
fit.  

vga16fb_imageblit in vga16fb.c
fbcon_show_logo in fbcon.c
fbcon_accel_putcs in fbcon-accel.c




[-- Attachment #2: changes.txt --]
[-- Type: text/plain, Size: 13428 bytes --]

/*
 * James, 
 *
 * fbcon_pixmap is where we construct the individual characters
 * into a single combined bitmap before submitting in one burst
 * to imageblit.
 * 
 * Since you removed fbcon_accel_setup already, fbcon_pixmap
 * can be statically allocated (max xres * max fontheight/8) which
 * should be 4096 for a 2048 xres and a fontheight of 16.  8192 may
 * be safer number.
 *
 * Also dynamic allocation segfaults when we do a kfree and hardware 
 * is still processing contents. This is where fb_sync() will be useful.
 */


static u8 *fbcon_pixmap = NULL;

void fbcon_accel_setup(struct display *p)
{
	if (fbcon_pixmap != NULL) {
		if (p->fb_info->fbops->fb_sync)
			p->fb_info->fbops->fb_sync(p->fb_info);
		kfree(fbcon_pixmap);
		fbcon_pixmap = NULL;
	}
	fbcon_pixmap = kmalloc(fontheight(p) * 
			     (p->fb_info->var.xres_virtual + 7)/8, 
			     GFP_KERNEL); 

	p->next_line = p->fb_info->fix.line_length;
	p->next_plane = 0;
}


void fbcon_accel_putcs(struct vc_data *vc, struct display *p,
		       const unsigned short *s, int count, int yy, int xx)
{
	struct fb_info *info = p->fb_info;
	unsigned short charmask = p->charmask;
	unsigned int width = ((fontwidth(p) + 7) >> 3);
	struct fb_image image;
	unsigned int cellsize = fontheight(p) * width;
	u16 c = scr_readw(s);

	image.fg_color = attr_fgcol(p, c);
	image.bg_color = attr_bgcol(p, c);
	image.dx = xx * fontwidth(p);
	image.dy = yy * fontheight(p);
	image.height = fontheight(p);
	image.depth = 1;

	if (!(fontwidth(p) & 7) && fbcon_pixmap != NULL) {
		unsigned int pitch = width * count, i, j;
		char *src, *dst, *dst0;

		dst0 = fbcon_pixmap;
		image.width = fontwidth(p) * count;
		image.data = fbcon_pixmap;
		while (count--) {
			src = p->fontdata + (scr_readw(s++) & charmask) * cellsize;
			dst = dst0;
			for (i = image.height; i--; ) {
				for (j = 0; j < width; j++) 
					dst[j] = *src++;
				dst += pitch;
			}
			dst0 += width;
		}
		info->fbops->fb_imageblit(info, &image);
	}
	else {
		image.width = fontwidth(p);
		while (count--) {
			image.data = p->fontdata +
				(scr_readw(s++) & charmask) * cellsize;
			info->fbops->fb_imageblit(info, &image);
			image.dx += fontwidth(p);
		}
	}
}


/*
 * fbcon_show_logo that supports drawing using fb_imageblit.  All packed
 * pixel formats (truecolor, directcolor, pseudocolor) should now be
 * supported.  It also supports logo drawing with vga-4-planes as pseudocolor
 * at 4 bpp.
 */
static int __init fbcon_show_logo( void )
{
    struct display *p = &fb_display[fg_console]; /* draw to vt in foreground */
    struct fb_info *info = p->fb_info;
#ifdef CONFIG_FBCON_ACCEL    
    struct fb_image image;
    u32 *palette = NULL, *saved_palette = NULL;
    char *logo_new = NULL;
#else 
    int line = p->next_line, x1, y1;
    unsigned char *dst, *src;
#endif
    int depth = info->var.bits_per_pixel;
    unsigned char *fb = info->screen_base;
    unsigned char *logo;
    int i, j, n, x;
    int logo_depth, done = 0;

    /* Return if the frame buffer is not mapped */
    if (!fb)
	return 0;
	
    /*
     * Set colors if visual is PSEUDOCOLOR and we have enough colors, or for
     * DIRECTCOLOR
     * We don't have to set the colors for the 16-color logo, since that logo
     * uses the standard VGA text console palette
     */
    if ((info->fix.visual == FB_VISUAL_PSEUDOCOLOR && depth >= 8) ||
	(info->fix.visual == FB_VISUAL_DIRECTCOLOR && depth >= 24))
	for (i = 0; i < LINUX_LOGO_COLORS; i += n) {
	    n = LINUX_LOGO_COLORS - i;
	    if (n > 16)
		/* palette_cmap provides space for only 16 colors at once */
		n = 16;
	    palette_cmap.start = 32 + i;
	    palette_cmap.len   = n;
	    for( j = 0; j < n; ++j ) {
		palette_cmap.red[j]   = (linux_logo_red[i+j] << 8) |
					linux_logo_red[i+j];
		palette_cmap.green[j] = (linux_logo_green[i+j] << 8) |
					linux_logo_green[i+j];
		palette_cmap.blue[j]  = (linux_logo_blue[i+j] << 8) |
					linux_logo_blue[i+j];
	    }
	    fb_set_cmap(&palette_cmap, 1, info);
	}
	
    if (depth >= 8) {
	logo = linux_logo;
	logo_depth = 8;
    }
    else if (depth >= 4) {
	logo = linux_logo16;
	logo_depth = 4;
    }
    else {
	logo = linux_logo_bw;
	logo_depth = 1;
    }
   
#if defined(CONFIG_FBCON_ACCEL)
	if (info->fix.visual == FB_VISUAL_TRUECOLOR || 
	    (info->fix.visual == FB_VISUAL_DIRECTCOLOR && depth >= 24)) {
		unsigned char mask[9] = { 0,0x80,0xc0,0xe0,0xf0,0xf8,0xfc,0xfe,0xff };
		unsigned char redmask, greenmask, bluemask;
		int redshift, greenshift, blueshift;

		/*
	 	 * We have to create a temporary palette since console palette is only
		 * 16 colors long.
	 	 */
		palette = kmalloc(256 * 4, GFP_KERNEL);
		if (palette == NULL)
			return (LOGO_H + fontheight(p) - 1) / fontheight(p);

		if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
			/* Bug: Doesn't obey msb_right ... (who needs that?) */
			redmask   = mask[info->var.red.length   < 8 ? info->var.red.length   : 8];
			greenmask = mask[info->var.green.length < 8 ? info->var.green.length : 8];
			bluemask  = mask[info->var.blue.length  < 8 ? info->var.blue.length  : 8];
			redshift   = info->var.red.offset   - (8 - info->var.red.length);
			greenshift = info->var.green.offset - (8 - info->var.green.length);
			blueshift  = info->var.blue.offset  - (8 - info->var.blue.length);


			for ( i = 0; i < LINUX_LOGO_COLORS; i++) {
				palette[i+32] = (safe_shift((linux_logo_red[i]   & redmask), redshift) |
						 safe_shift((linux_logo_green[i] & greenmask), greenshift) |
						 safe_shift((linux_logo_blue[i]  & bluemask), blueshift));
			}
		}
		else {
			redshift = info->var.red.offset;
			greenshift = info->var.green.offset;
			blueshift = info->var.blue.offset;

			for (i = 32; i < LINUX_LOGO_COLORS; i++) 
				palette[i] = i << redshift | i << greenshift | i << blueshift;
		}
		saved_palette = info->pseudo_palette;
		info->pseudo_palette = palette;
	}
	else if (info->fix.visual == FB_VISUAL_DIRECTCOLOR && depth >= 12 && depth < 24) {
		logo_new = kmalloc(LOGO_W * LOGO_H, GFP_KERNEL);
		if (logo_new == NULL)
			return (LOGO_H + fontheight(p) - 1) / fontheight(p);

		logo = logo_new;
		for (i = 0; i < (LOGO_W * LOGO_H)/2; i++) {
			logo_new[i*2] = linux_logo16[i] >> 4;
			logo_new[(i*2)+1] = linux_logo16[i] & 0xf;
		}
	} 
	image.width = LOGO_W;
	image.height = LOGO_H;
	image.depth = depth;
	image.data = logo;
	image.dy = 0;
#endif
 
    for (x = 0; x < num_online_cpus() * (LOGO_W + 8) &&
    	 x < info->var.xres - (LOGO_W + 8); x += (LOGO_W + 8)) {
#if defined (CONFIG_FBCON_ACCEL)
	image.dx = x;
	info->fbops->fb_imageblit(info, &image);
	done = 1;
#endif
#if defined(CONFIG_FBCON_AFB) || defined(CONFIG_FBCON_ILBM) || \
    defined(CONFIG_FBCON_IPLAN2P2) || defined(CONFIG_FBCON_IPLAN2P4) || \
    defined(CONFIG_FBCON_IPLAN2P8)
	if (depth >= 2 && (info->fix.type == FB_TYPE_PLANES ||
			   info->fix.type == FB_TYPE_INTERLEAVED_PLANES)) {
	    /* planes (normal or interleaved), with color registers */
	    int bit;
	    unsigned char val, mask;
	    int plane = p->next_plane;

#if defined(CONFIG_FBCON_IPLAN2P2) || defined(CONFIG_FBCON_IPLAN2P4) || \
    defined(CONFIG_FBCON_IPLAN2P8)
	    int line_length = info->fix.line_length;

	    /* for support of Atari interleaved planes */
#define MAP_X(x)	(line_length ? (x) : ((x) & ~1)*depth + ((x) & 1))
#else
#define MAP_X(x)	(x)
#endif
	    /* extract a bit from the source image */
#define	BIT(p,pix,bit)	(p[pix*logo_depth/8] & \
			 (1 << ((8-((pix*logo_depth)&7)-logo_depth) + bit)))
		
	    src = logo;
	    for( y1 = 0; y1 < LOGO_H; y1++ ) {
		for( x1 = 0; x1 < LOGO_LINE; x1++, src += logo_depth ) {
		    dst = fb + y1*line + MAP_X(x/8+x1);
		    for( bit = 0; bit < logo_depth; bit++ ) {
			val = 0;
			for( mask = 0x80, i = 0; i < 8; mask >>= 1, i++ ) {
			    if (BIT( src, i, bit ))
				val |= mask;
			}
			*dst = val;
			dst += plane;
		    }
		}
	    }
	
	    /* fill remaining planes */
	    if (depth > logo_depth) {
		for( y1 = 0; y1 < LOGO_H; y1++ ) {
		    for( x1 = 0; x1 < LOGO_LINE; x1++ ) {
			dst = fb + y1*line + MAP_X(x/8+x1) + logo_depth*plane;
			for( i = logo_depth; i < depth; i++, dst += plane )
			    *dst = 0x00;
		    }
		}
	    }
	    done = 1;
	    break;
	}
#endif
#if defined(CONFIG_FBCON_MFB) || defined(CONFIG_FBCON_AFB) || \
    defined(CONFIG_FBCON_ILBM) || defined(CONFIG_FBCON_HGA)

	if (depth == 1 && (info->fix.type == FB_TYPE_PACKED_PIXELS ||
			   info->fix.type == FB_TYPE_PLANES ||
			   info->fix.type == FB_TYPE_INTERLEAVED_PLANES)) {

	    /* monochrome */
	    unsigned char inverse = p->inverse || info->fix.visual == FB_VISUAL_MONO01
		? 0x00 : 0xff;

	    int is_hga = !strncmp(info->modename, "HGA", 3);
	    /* can't use simply memcpy because need to apply inverse */
	    for( y1 = 0; y1 < LOGO_H; y1++ ) {
		src = logo + y1*LOGO_LINE;
		if (is_hga)
		    dst = fb + (y1%4)*8192 + (y1>>2)*line + x/8;
		else
		    dst = fb + y1*line + x/8;
		for( x1 = 0; x1 < LOGO_LINE; ++x1 )
		    fb_writeb(*src++ ^ inverse, dst++);
	    }
	    done = 1;
	}
#endif
#if defined(CONFIG_FBCON_VGA_PLANES)
	if (depth == 4 && info->fix.type == FB_TYPE_VGA_PLANES) {
		outb_p(1,0x3ce); outb_p(0xf,0x3cf);
		outb_p(3,0x3ce); outb_p(0,0x3cf);
		outb_p(5,0x3ce); outb_p(0,0x3cf);

		src = logo;
		for (y1 = 0; y1 < LOGO_H; y1++) {
			for (x1 = 0; x1 < LOGO_W / 2; x1++) {
				dst = fb + y1*line + x1/4 + x/8;

				outb_p(0,0x3ce);
				outb_p(*src >> 4,0x3cf);
				outb_p(8,0x3ce);
				outb_p(1 << (7 - x1 % 4 * 2),0x3cf);
				fb_readb (dst);
				fb_writeb (0, dst);

				outb_p(0,0x3ce);
				outb_p(*src & 0xf,0x3cf);
				outb_p(8,0x3ce);
				outb_p(1 << (7 - (1 + x1 % 4 * 2)),0x3cf);
				fb_readb (dst);
				fb_writeb (0, dst);

				src++;
			}
		}
		done = 1;
	}
#endif
    }
   
#if defined (CONFIG_FBCON_ACCEL)
	if (palette != NULL)
		kfree(palette);
	if (saved_palette != NULL)
		info->pseudo_palette = saved_palette;
	if (logo_new != NULL)
		kfree(logo_new);
#endif
    /* Modes not yet supported: packed pixels with depth != 8 (does such a
     * thing exist in reality?) */

    return done ? (LOGO_H + fontheight(p) - 1) / fontheight(p) : 0 ;
}


/*
 * The following is a vga imageblit that supports bitmaps greater than
 * 8 pixels wide and logo drawing in vga-4-planes.
 *
 * I haven't made any changes to the other VGA formats.  No hardware.
 */

void vga_imageblit_expand(struct fb_info *info, struct fb_image *image)
{
	char *where = info->screen_base + (image->dx/8) + 
		image->dy * info->fix.line_length;
	struct vga16fb_par *par = (struct vga16fb_par *) info->par;
	u8 *cdat = image->data, *dst;
	int x, y;

	switch (info->fix.type) {
		case FB_TYPE_VGA_PLANES:
			if (info->fix.type_aux == FB_AUX_VGA_PLANES_VGA4) {
				if (par->isVGA) {
					setmode(2);
					setop(0);
					setsr(0xf);
					setcolor(image->fg_color);
					selectmask();

					setmask(0xff);
					writeb(image->bg_color, where);
					rmb();
					readb(where); /* fill latches */
					setmode(3);
					wmb();
					for (y = 0; y < image->height; y++) {
						dst = where;
						for (x = image->width/8; x--;) 
							writeb(*cdat++, dst++);
						where += info->fix.line_length;
					}
					wmb();
				} else {
					setmode(0);
					setop(0);
					setsr(0xf);
					setcolor(image->bg_color);
					selectmask();

					setmask(0xff);
					for (y = 0; y < image->height; y++) {
						dst = where;
						for (x=image->width/8; x--;){
							rmw(dst);
							setcolor(image->fg_color);
							selectmask();
							if (*cdat) {
								setmask(*cdat++);
								rmw(dst++);
							}
						}
						where += info->fix.line_length;
					}
				}
			} else 
				vga_8planes_imageblit(info, image);
			break;
#ifdef FBCON_HAS_VGA
		case FB_TYPE_TEXT:
			break;
#endif
		case FB_TYPE_PACKED_PIXELS:
		default:
			cfb_imageblit(info, image);
			break;
	}
}

void vga_imageblit_color(struct fb_info *info, struct fb_image *image) 
{
	/*
	 * Draw logo 
	 */
	struct vga16fb_par *par = (struct vga16fb_par *) info->par;
	char *where = info->screen_base + image->dy * info->fix.line_length + 
		image->dx/8;
	char *cdat = image->data, *dst;
	int x, y;

	switch (info->fix.type) {
	case FB_TYPE_VGA_PLANES:
		if (info->fix.type_aux == FB_AUX_VGA_PLANES_VGA4 &&
		    par->isVGA) {
			setsr(0xf);
			setop(0);
			setmode(0);
			
			for (y = 0; y < image->height; y++) {
				for (x = 0; x < image->width/2; x++) {
					dst = where + x/4;

					setcolor(*cdat >> 4);
					selectmask();
					setmask(1 << (7 - x % 4 * 2));
					fb_readb(dst);
					fb_writeb(0, dst);

					setcolor(*cdat & 0xf);
					selectmask();
					setmask(1 << (7 - (1 + x % 4 * 2)));
					fb_readb(dst);
					fb_writeb(0, dst);

					cdat++;
				}
				where += info->fix.line_length;
			}
		}
		break;
	case FB_TYPE_PACKED_PIXELS:
		cfb_imageblit(info, image);
		break;
	default:
		break;
	}
}
				
void vga16fb_imageblit(struct fb_info *info, struct fb_image *image)
{
	if (image->depth == 1)
		vga_imageblit_expand(info, image);
	else if (image->depth == info->var.bits_per_pixel)
		vga_imageblit_color(info, image);
}

Re: status

[Antonino Daplas]

On Sat, 2002-11-23 at 00:04, James Simmons wrote:
> 
> > Any patches in the meantime?  I have a few changes I can pass to you:
> 
> Yes of course!!!!
> 
I mean, do you have patches against vanilla linux?  I currently don't
have bk right now.  I browsed the bk repository, and it seems you made a
lot of changes.

> > 1. optimized putcs to speed up scrolling by 2-3x.  (it's a small patch
> > but it already outperforms fb-2.4 especially at high color depths).
> > Compared with the previous patch I submitted, this change is
> > non-intrusive, so no other changes are required.
> >
> > 2. vga16fb imageblit that supports drawing of the penguin (vga-4-planes
> > only)
> > 
> > 3. logo drawing for directcolor visuals.
> 
> Please send me those patches ASAP!!! I will linclude them right away.
I can, but against 2.5.48 only + your old fbdev.diff.  You might have a
hard time merging it to your repository.

>  
> > The above should complete softaccel support for most hardware except for
> > the more esoteric ones (mostly authored by Geert).
> 
> Geert is busy porting the Amigia driver to the new api. That means all the 
> ilbm, iplan stuff will go away :-) 
> 
> > Also cfbcursor is a bit misleading, no?  It implies support for
> > packed-pixels only, but I already  use it with vga16fb.
> 
> OOps. You are right. What should we call it?
> 
I don't know, gen_cursor?

Tony




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: status

[Antonino Daplas]

On Fri, 2002-11-22 at 22:52, James Simmons wrote:
> 
> Hi folks!!!
> 
>    Just to let you know where I am for the fbdev developement. I finished 
> off the latest api changes. The cursor api has been cleaned up and it uses 
> fb_image struct. This makes life easier. 
>    I ported over the ATI 128 driver to the latest changes. I finished the 
> 3Dfx driver yesterday and got the ATI mach 64 driver done this morning.
> I will test it tomorrow. Then I will finsih up the NVIDIA driver. After 
> that I'm going to push the code to linus. 
Any patches in the meantime?  I have a few changes I can pass to you:

1. optimized putcs to speed up scrolling by 2-3x.  (it's a small patch
but it already outperforms fb-2.4 especially at high color depths).
Compared with the previous patch I submitted, this change is
non-intrusive, so no other changes are required.

2. vga16fb imageblit that supports drawing of the penguin (vga-4-planes
only)

3. logo drawing for directcolor visuals.

The above should complete softaccel support for most hardware except for
the more esoteric ones (mostly authored by Geert).

Also cfbcursor is a bit misleading, no?  It implies support for
packed-pixels only, but I already  use it with vga16fb.

Tony 




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: status

[James Simmons]

> Any patches in the meantime?  I have a few changes I can pass to you:

Yes of course!!!!

> 1. optimized putcs to speed up scrolling by 2-3x.  (it's a small patch
> but it already outperforms fb-2.4 especially at high color depths).
> Compared with the previous patch I submitted, this change is
> non-intrusive, so no other changes are required.
>
> 2. vga16fb imageblit that supports drawing of the penguin (vga-4-planes
> only)
> 
> 3. logo drawing for directcolor visuals.

Please send me those patches ASAP!!! I will linclude them right away.
 
> The above should complete softaccel support for most hardware except for
> the more esoteric ones (mostly authored by Geert).

Geert is busy porting the Amigia driver to the new api. That means all the 
ilbm, iplan stuff will go away :-) 

> Also cfbcursor is a bit misleading, no?  It implies support for
> packed-pixels only, but I already  use it with vga16fb.

OOps. You are right. What should we call it?



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

status

[James Simmons]

Hi folks!!!

   Just to let you know where I am for the fbdev developement. I finished 
off the latest api changes. The cursor api has been cleaned up and it uses 
fb_image struct. This makes life easier. 
   I ported over the ATI 128 driver to the latest changes. I finished the 
3Dfx driver yesterday and got the ATI mach 64 driver done this morning.
I will test it tomorrow. Then I will finsih up the NVIDIA driver. After 
that I'm going to push the code to linus. 
   I started to hack at fbcon.c but realized it is such a mess I am going 
to rewrite it from scratch. This will be after the push to linus. I plan 
to use MDA console and create a modular fbcon that I can play with at 
will. 
   The other annoucement is I have started to look for funding for this 
developement. At present I haven't found anything. I realized for the 
fbdev and console changes to be done I need to devote all my time to do 
this. To do this will require funding so I can pay my most basic bills. 
Wish me luck.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: status

[William Knop]

Ah, doesn't NFSv3 not support concurrent reads? Or concurrent reads while a 
file is open for writing or something like that? Concurrent writes would be 
useful, but is not necessarily required (we could hack around it). Idealy, 
we'd like to have a job continue to read off the version of a file it 
started reading on, such that when the file already opened for reading is 
opened for writing, the file is duplicated, the duplicate writen to (now the 
new version), then deleted once the initial job closes the file for reading. 
This could result in many versions of the same file, but only as long as 
they are open for reading. It would be nice if I could open a file for a 
"sustained read" or some such, so only big jobs would receive the special 
treatment of getting their own temporary version of a file.


>NFSv4 for Linux is about three months out.  a beta quality                  
>                                                                            
>                 > client will be available soon, but the server is farther 
>                                                                            
>                                    > out.                                  
>                                                                            
>                                                                            
>                                                                            
>                                                                        > 
>what are your performance requirements, and why do you                      
>                                                                            
>                 > think NFSv3 won't meet them?
>
>
> > I'm setting up a distributed/clustering filesystem for a                 
>                                                                            
>                  > > research group and                                    
>                                                                            
>                                     > > would like some info/advise.       
>                                                                            
>                                                        > >                 
>                                                                            
>                                                                           
> > > NFSv4 looks pretty sweet, but is it ready for beta                     
>                                                                            
>                    > > deployment? We'll need to                           
>                                                                            
>                                       > > have everything up and stable 
>fairly soon, but so far it                                                  
>                                                            > > seems like 
>NFSv4 is                                                                    
>                                                                            
>    > > the only open source FS out there that will satisfy our             
>                                                                            
>                       > > requirements, of                                 
>                                                                            
>                                          > > which the main ones are 
>partial-file caching and support for                                        
>                                                                  > > large 
>(100GB+)                                                                    
>                                                                            
>         > > filesystems.                                                   
>                                                                            
>                            > >                                             
>                                                                            
>                                               > > Intermezzo forces whole 
>file caching, which will not do.                                            
>                                                                  > > 
>OpenGFS I believe                                                           
>                                                                            
>               > > is still in alpha stage. OpenAFS only allows for very 
>small                                                                       
>                                    > > filesystems.                        
>                                                                            
>                                                       > > EVMS looks 
>promising, but the clustering FS part is still                              
>                                                                            
>    > > alpha. I think                                                      
>                                                                            
>                       > > NFSv3 has poor performance, although it would be 
>excellent if                                                                
>                                         > > it would work.                 
>                                                                            
>                                                            > >             
>                                                                            
>                                                                            
>    > > I'd greatly appreciate any info on distributed/clustering           
>                                                                            
>                       > > filesystems,                                     
>                                                                            
>                                          > > especially NFSv4 or stable 
>alternatives.
> > > Thanks much,
> > William Knop

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail



-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Status

[William J. Earl]

ralf@uni-koblenz.de writes:
...
 > > What we need to do is make it easy for Linux to determine what
 > > chipsets are attached to the cpu.  Bill Earl might have some straightforward
 > > answers.  I'm in favor of simply publishing the relevant sections
 > > of Irix bootstrap code.  Perhaps Santa Claus can make a code drop this year.
 > 
 > Isn't that ``Full House'' vs. ``Guiness''?  Linux knows that difference since
 > it is running on the Indy.

       The basic difference is between "FullHouse" (Indigo2) and "Guinness"
(Indy).  Beyond that, there are smaller differences between Indy and Challenge S.
Challenge S does have an extra SCSI channel, but the configuration is not
identical to Indigo2.  (I will look into that later.)

      I am still working on an agreement to release more technical information
about a variety of our systems.  

Re: Status

[ralf]

On Wed, Dec 23, 1998 at 09:51:36AM -0800, Greg Chesson wrote:

> Indy, I2, and Challenge-S are all related.
> Challenge-S is an Indy (small blue box) with the media stuff removed,
> with basically the same motherboard.  I don't know for sure whether
> it has the extra SCSI channel like the I2.  The I2 is a different
> motherboard in a larger (than Indy) box.  Core chipsets are the same.
> 
> What we need to do is make it easy for Linux to determine what
> chipsets are attached to the cpu.  Bill Earl might have some straightforward
> answers.  I'm in favor of simply publishing the relevant sections
> of Irix bootstrap code.  Perhaps Santa Claus can make a code drop this year.

Isn't that ``Full House'' vs. ``Guiness''?  Linux knows that difference since
it is running on the Indy.

  Ralf

Re: Status

[Greg Chesson]

Indy, I2, and Challenge-S are all related.
Challenge-S is an Indy (small blue box) with the media stuff removed,
with basically the same motherboard.  I don't know for sure whether
it has the extra SCSI channel like the I2.  The I2 is a different
motherboard in a larger (than Indy) box.  Core chipsets are the same.

What we need to do is make it easy for Linux to determine what
chipsets are attached to the cpu.  Bill Earl might have some straightforward
answers.  I'm in favor of simply publishing the relevant sections
of Irix bootstrap code.  Perhaps Santa Claus can make a code drop this year.

g

-- 
Greg Chesson

Re: Status

[Dave Olson]

Alex deVries wrote: 
|  On Mon, 21 Dec 1998, Greg Chesson wrote:
|  > I2 means Indigo2.
|  > Extreme means he has a high-end graphics board.
|  > The I2 is like the Indy, but has two built-in SCSI channels rather
|  > than one.  It tends to not have all the multi-media stuff on the motherboard
|  > that you find on the Indy.  I have an I2 because - unlike the Indy -
|  > I can put two XL graphics cards in it and run a two-head display.
|  > The I2 also allows for an Extreme card and an XL (but not 2 Extreme's).
|  > Also, can have more memory than an Indy.
|  
|  The Indigo2 sounds a lot like a Challenge S; is the internal architecture
|  similiar to the Indy/Challenge S as well?

Yes.  Indigo2 came first, then Indy was done as a derivitive of it.
Indy left out EISA, and changed to an integrated chip for the serial
ports and a couple of other things, as a cost reduction measure.
Indy also has only one scsi controller, while indigo2 has two.
Challenge S was then done as a derivitive of Indy, with the graphics
board replaced by a board with the wd95 scsi controllers, and two GIO
slots (only one of which could do DMA).

Re: Status

[Dave Olson]

Alex deVries wrote: 
|  On Mon, 21 Dec 1998, Greg Chesson wrote:
|  > I2 means Indigo2.
|  > Extreme means he has a high-end graphics board.
|  > The I2 is like the Indy, but has two built-in SCSI channels rather
|  > than one.  It tends to not have all the multi-media stuff on the motherboard
|  > that you find on the Indy.  I have an I2 because - unlike the Indy -
|  > I can put two XL graphics cards in it and run a two-head display.
|  > The I2 also allows for an Extreme card and an XL (but not 2 Extreme's).
|  > Also, can have more memory than an Indy.
|  
|  The Indigo2 sounds a lot like a Challenge S; is the internal architecture
|  similiar to the Indy/Challenge S as well?

Yes.  Indigo2 came first, then Indy was done as a derivitive of it.
Indy left out EISA, and changed to an integrated chip for the serial
ports and a couple of other things, as a cost reduction measure.
Indy also has only one scsi controller, while indigo2 has two.
Challenge S was then done as a derivitive of Indy, with the graphics
board replaced by a board with the wd95 scsi controllers, and two GIO
slots (only one of which could do DMA).

Re: Status

[Alex deVries]

On Mon, 21 Dec 1998, Greg Chesson wrote:
> I2 means Indigo2.
> Extreme means he has a high-end graphics board.
> The I2 is like the Indy, but has two built-in SCSI channels rather
> than one.  It tends to not have all the multi-media stuff on the motherboard
> that you find on the Indy.  I have an I2 because - unlike the Indy -
> I can put two XL graphics cards in it and run a two-head display.
> The I2 also allows for an Extreme card and an XL (but not 2 Extreme's).
> Also, can have more memory than an Indy.

The Indigo2 sounds a lot like a Challenge S; is the internal architecture
similiar to the Indy/Challenge S as well?

- Alex

Re: Status

[Greg Chesson]

I2 means Indigo2.
Extreme means he has a high-end graphics board.

The I2 is like the Indy, but has two built-in SCSI channels rather
than one.  It tends to not have all the multi-media stuff on the motherboard
that you find on the Indy.  I have an I2 because - unlike the Indy -
I can put two XL graphics cards in it and run a two-head display.
The I2 also allows for an Extreme card and an XL (but not 2 Extreme's).
Also, can have more memory than an Indy.

g

-- 
Greg Chesson

Re: Status

[Alex deVries]

On Mon, 21 Dec 1998, Ariel Faigon wrote:
> :I am sorry if this is an issue stated in a faq or updated document
> :or something. But, how far are we exactly?
> :I have an I2 Extreme (R4.4 200).. I doubt I can run linux on it yet.
> :But, it's an interesting thought. And, well.the webpage
> :doesn't seem tooo updated :)

What's in an I2 Extreme exactly?

- Alex

Re: Status

[Mark A. Zottola]

I guess I should probably interject a point of information on this thread.
Both myself and 2 colleagues at UAB will be extending the port of Linux to
the Indigo2 platform as part of a project funded by SGI to build a Beowulf
cluster consisting of Indigo2's. We are waiting to receive these machines
and intend to begin earnest work after the new year. So I hope we can
contribute a change in the information content of said pages in the near
future.

Mark

Honza Pazdziora wrote:

>
> As for the HW specs, the pages stated for a long time that only Indys
> are supported and we've said that on the pages.
>
> Yours,
>
> ------------------------------------------------------------------------
>  Honza Pazdziora | adelton@fi.muni.cz | http://www.fi.muni.cz/~adelton/
>                 Boycott the Czech Telecom -- www.bojkot.cz
> ------------------------------------------------------------------------

--
*********
Mark A. Zottola                       Alabama Research and Education Network

119 Rust Research Center              Nichols Research Corporation
University of Alabama-Birmingham      VOICE:  (205) 934-3893
Birmingham, AL  35294                 EMAIL:  asnmaz01@csimail.asc.edu

Re: Status

[Honza Pazdziora]

> 
> P.S.
> We are still looking for a volunteer to keep the web site
> more up to date.

Well, I know you are pointing at me, but I really didn't see much
changes that should make their way to the web during last months. But
I'm only following this list, not other linux-kernel's. Did I miss
something?

As for the HW specs, the pages stated for a long time that only Indys
are supported and we've said that on the pages.

Yours,

------------------------------------------------------------------------
 Honza Pazdziora | adelton@fi.muni.cz | http://www.fi.muni.cz/~adelton/
		Boycott the Czech Telecom -- www.bojkot.cz
------------------------------------------------------------------------

Re: Status

[Ariel Faigon]

:
:Hello,
:
:I am sorry if this is an issue stated in a faq or updated document
:or something. But, how far are we exactly?
:I have an I2 Extreme (R4.4 200).. I doubt I can run linux on it yet.
:But, it's an interesting thought. And, well.the webpage
:doesn't seem tooo updated :)
:
:Fredrik
:

Well.  I just updated the FAQ with this frequently asked question :-)


P.S.
We are still looking for a volunteer to keep the web site
more up to date.

-- 
Peace, Ariel

Re: Status

[Ariel Faigon]

:
:Hello,
:
:I am sorry if this is an issue stated in a faq or updated document
:or something. But, how far are we exactly?
:I have an I2 Extreme (R4.4 200).. I doubt I can run linux on it yet.
:But, it's an interesting thought. And, well.the webpage
:doesn't seem tooo updated :)
:
:Fredrik
:

Well.  I just updated the FAQ with this frequently asked question :-)


P.S.
We are still looking for a volunteer to keep the web site
more up to date.

-- 
Peace, Ariel

Status

[Fredrik Rovik]

Hello,

I am sorry if this is an issue stated in a faq or updated document
or something. But, how far are we exactly?
I have an I2 Extreme (R4.4 200).. I doubt I can run linux on it yet.
But, it's an interesting thought. And, well.the webpage
doesn't seem tooo updated :)

Fredrik



______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com