headers
shentino | 1 Jun 2009 21:15
Picon

What makes a good filesystem?

I've got a vague itch to write a file system, for an academic exercise
if nothing else, and I'm curious about what good filesystem design is
all about.  Particularly any properties that a filesystem design
must have and/or should have to pass muster with the fs guys, and doubly
particular how important these properties are.

Besides the usual preemption safety/locking/smp awareness and all that
stuff that's a given for kernel code in general, what are good
principles to code for when you're designing a filesystem?

In particular what I'm curious about includes but is by no means limited
to the following:
1.  POSIX compliance (given, probably trivial to research)
2.  Integrity in the presence of catastrophic interruptions (crashes,
kernel panics, power outages, random reboots) (I'm guessing a Good
Thing)
3.  Performance (given)
4.  Robustness in the presence of flaky media (unsure how mandatory or
required this is)
5.  Anything I missed

I'm intrigued by btrfs and tux3, and also a tad envious of the brains
behind them.

--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo <at> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rajat Jain | 18 Jun 2009 14:49
Favicon

MSI on Intel APIC


Hello list,

My query has to do with Intel Hardware and MSI (rather than its
implementation in Linux) but trying my luck to see if anyone has any
suggestions here. I have an OS independent qury on the MSI using
Intel-APIC (945 chipset). 

I'm trying to make MSI work on a custom OS, and I'm working on the
system "bus driver" level rather than at the device driver level. I
understand that to generate MSI, the device function will generate PCI
write transaction to write the contents of its MDR into address
specified in MAR. This is currently not generating the MSI for my
device. 

To blame the device as faulty or to keep Intel processor out of
suspicion, I want to prove that writing the contents of MDR into the
address specified by MAR ACTUALLY will generate an interrupt to the
processor. Is there a way I can prove that by a demonstration in SW?

I wrote a small piece of code that does what the device HW is supposed
to do. It writes the "a value" into "an address" and expects to generate
an interrupt to processor as a result. Please note that this "value" and
"address" are calculated in accordance with sec 9.12 (MSI) of ""Intel(r)
64 and IA-32 Architectures Software Developer's Manual"
(http://www.intel.com/Assets/PDF/manual/253668.pdf) 

Also note that this "value" and "address" is really what will be
programmed into MDR and MAR respectively on the device. But the end
result is that when my demo code does exactly what the PCI device is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pei Lin | 19 Jun 2009 04:43
Picon

Re: MSI on Intel APIC

look at your local APIC error status register = 0x80,
reference as "9.6.3 Error Handling",it imply
"Illegal Reg. Address:
(Intel Core, Intel Atom, Pentium 4, Intel Xeon, and P6 family
processors only) Set when the processor is trying to access a register
in the processor's local APIC register address space that is reserved
(see Table 9-1). Addresses in one of the 0x10 byte regions marked
reserved are illegal register addresses.
The Local APIC Register Map is the address range of the APIC register
base address (specified in the IA32_APIC_BASE MSR) plus 4 KBytes."

i guess there are something wrong with your address space
configuration.Refer to the specification "PCI Local Bus Specification"
Chapter 6 Configuration Space for a check.

ps.  i am just a newbie for PCI and APIC,hope this can give u some clues.

BRs
lin

2009/6/18 Rajat Jain <Rajat.Jain <at> infogain.com>:
>
> Hello list,
>
> My query has to do with Intel Hardware and MSI (rather than its
> implementation in Linux) but trying my luck to see if anyone has any
> suggestions here. I have an OS independent qury on the MSI using
> Intel-APIC (945 chipset).
>
> I'm trying to make MSI work on a custom OS, and I'm working on the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rajat Jain | 19 Jun 2009 07:40
Favicon

RE: MSI on Intel APIC


Hello Pei / Tom,

Thanks for the response. Actually I understand why the error is coming,
but my question is a little different.

I'm saying that I understand that MSI works like following:

1) The device is given "an address" and a "value" (using MAR & MDR
registers) that it can use later on to generate an interrupt. 
2) The device later on when wants to send an interrupt, simply write
this "value" into that address using a PCI write transaction.
3) This "address" and "value" is decided by the Intel APIC architecture
(described in section 9.12 (MSI) of ""Intel 64 and IA-32 Architectures
Software Developer's Manual"
http://www.intel.com/Assets/PDF/manual/253668.pdf).
4) It is the responsibility of the Intel APIC to generate an interrupt
to the processor when that "value" is written to that "address". 

Now my question is simply this:

Question
========
APIC generates an interrupt when the device writes that "value" into
that "address". But will it also generate an interrupt if a SOFTWARE
writes that same "value" into the same "address"????

Currently, my software tries the same and gets the APIC error interrupt.
Which is partly justified by the section 9.6.3 (Illegal register access)
since the "address" specified by the same specification (sec 9.12.1)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pei Lin | 19 Jun 2009 10:54
Picon

Re: MSI on Intel APIC

i doubt your hardware write the bus address which is the same address
as your software "see".

i also expect who can give me the answer.... ^-^

BRs,
Lin

2009/6/19 Rajat Jain <Rajat.Jain <at> infogain.com>:
>
> Hello Pei / Tom,
>
> Thanks for the response. Actually I understand why the error is coming,
> but my question is a little different.
>
> I'm saying that I understand that MSI works like following:
>
> 1) The device is given "an address" and a "value" (using MAR & MDR
> registers) that it can use later on to generate an interrupt.
> 2) The device later on when wants to send an interrupt, simply write
> this "value" into that address using a PCI write transaction.
> 3) This "address" and "value" is decided by the Intel APIC architecture
> (described in section 9.12 (MSI) of ""Intel 64 and IA-32 Architectures
> Software Developer's Manual"
> http://www.intel.com/Assets/PDF/manual/253668.pdf).
> 4) It is the responsibility of the Intel APIC to generate an interrupt
> to the processor when that "value" is written to that "address".
>
> Now my question is simply this:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
pradeep singh | 19 Jun 2009 12:43
Picon

Re: bridging teo bride two virtual devices?

On Fri, Jun 19, 2009 at 2:47 PM, Tekale
Sharad-FHJN78<FHJN78 <at> motorola.com> wrote:
> Hi,
>
> Is it possible to bride two virtual devices?

You mean virtual network devices?
If yes, then yes you can bridge them.
>
> If so, are there any draw backs due to it.

Draw backs in what terms you mean?
performance, memory usage or anything else?

Thanks,
>
> Thanks and Regards,
> Sharad.

--

-- 
Pradeep
--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo <at> 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 | Reply | 0 comments |
headers
Peter Teoh | 21 Jun 2009 13:56
Picon
Gravatar

Re: MSI on Intel APIC

On Fri, Jun 19, 2009 at 1:40 PM, Rajat Jain<Rajat.Jain <at> infogain.com> wrote:
>
> Hello Pei / Tom,
>
> Thanks for the response. Actually I understand why the error is coming,
> but my question is a little different.
>
> I'm saying that I understand that MSI works like following:
>
> 1) The device is given "an address" and a "value" (using MAR & MDR
> registers) that it can use later on to generate an interrupt.
> 2) The device later on when wants to send an interrupt, simply write
> this "value" into that address using a PCI write transaction.
> 3) This "address" and "value" is decided by the Intel APIC architecture
> (described in section 9.12 (MSI) of ""Intel 64 and IA-32 Architectures
> Software Developer's Manual"
> http://www.intel.com/Assets/PDF/manual/253668.pdf).
> 4) It is the responsibility of the Intel APIC to generate an interrupt
> to the processor when that "value" is written to that "address".
>
> Now my question is simply this:
>
> Question
> ========
> APIC generates an interrupt when the device writes that "value" into
> that "address". But will it also generate an interrupt if a SOFTWARE

normally, when a device write to an address, it is a physical address
from the device's perspective.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pei Lin | 22 Jun 2009 03:46
Picon

Re: MSI on Intel APIC

i think the "bus address" is not always equality to "physical
address".In X86 ,maybe they are the same,but i think it associate with
the hardware.
i think Rajat's software is not a linux driver, it is the low level
under the OS. PCI firmware, right?

If i was wrong, correct me. Thanks.
Reference:
Document/IO-mapping.txt
http://en.wikipedia.org/wiki/Peripheral_Component_Interconnect

BRs

lin,

2009/6/21 Peter Teoh <htmldeveloper <at> gmail.com>:
> On Fri, Jun 19, 2009 at 1:40 PM, Rajat Jain<Rajat.Jain <at> infogain.com> wrote:
>>
>> Hello Pei / Tom,
>>
>> Thanks for the response. Actually I understand why the error is coming,
>> but my question is a little different.
>>
>> I'm saying that I understand that MSI works like following:
>>
>> 1) The device is given "an address" and a "value" (using MAR & MDR
>> registers) that it can use later on to generate an interrupt.
>> 2) The device later on when wants to send an interrupt, simply write
>> this "value" into that address using a PCI write transaction.
>> 3) This "address" and "value" is decided by the Intel APIC architecture
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rajat Jain | 22 Jun 2009 06:46
Favicon

RE: MSI on Intel APIC


Hello Peter,

Yes, I'm using a virtual address to write to that physical address (I'm
building page tables myself, something like what ioremap() does) 

:-(

Rajat 

> -----Original Message-----
> From: Peter Teoh [mailto:htmldeveloper <at> gmail.com] 
> Sent: Sunday, June 21, 2009 5:26 PM
> To: Rajat Jain
> Cc: Pei Lin; kernelnewbies <at> nl.linux.org; 
> linux-newbie <at> vger.kernel.org; Nguyen, Tom L
> Subject: Re: MSI on Intel APIC
> 
> On Fri, Jun 19, 2009 at 1:40 PM, Rajat 
> Jain<Rajat.Jain <at> infogain.com> wrote:
> >
> > Hello Pei / Tom,
> >
> > Thanks for the response. Actually I understand why the 
> error is coming,
> > but my question is a little different.
> >
> > I'm saying that I understand that MSI works like following:
> >
> > 1) The device is given "an address" and a "value" (using MAR & MDR
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Teoh | 23 Jun 2009 02:27
Picon
Gravatar

Re: MSI on Intel APIC

welll....thanks PeiLin for pointing out the doc:   DMA-mapping.txt,
and IO-mapping.txt.   These explained very well what is needed to be
done.   but issue now is how Rajat build his own page table?   care to
show the code snippets?   did u verify it is working?  and how?   :-).

thanks.

On Mon, Jun 22, 2009 at 12:46 PM, Rajat Jain<Rajat.Jain <at> infogain.com> wrote:
>
> Hello Peter,
>
> Yes, I'm using a virtual address to write to that physical address (I'm
> building page tables myself, something like what ioremap() does)
>
> :-(
>
> Rajat
>
>> -----Original Message-----
>> From: Peter Teoh [mailto:htmldeveloper <at> gmail.com]
>> Sent: Sunday, June 21, 2009 5:26 PM
>> To: Rajat Jain
>> Cc: Pei Lin; kernelnewbies <at> nl.linux.org;
>> linux-newbie <at> vger.kernel.org; Nguyen, Tom L
>> Subject: Re: MSI on Intel APIC
>>
>> On Fri, Jun 19, 2009 at 1:40 PM, Rajat
>> Jain<Rajat.Jain <at> infogain.com> wrote:
>> >
>> > Hello Pei / Tom,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane