Re: Inlined code

[Sebastian Huber]

On 06/08/18 21:14, Joel Sherrill wrote:



On Mon, Aug 6, 2018 at 1:21 AM, Chris Johns > wrote:


On 06/08/2018 16:12, Christian Mauderer wrote:
> Am 06.08.2018 um 07:31 schrieb Chris Johns:
>> On 06/08/2018 10:51, Chris Johns wrote:
>>> On 05/08/2018 19:39, Christian Mauderer wrote:
 Am 05.08.2018 um 04:00 schrieb Chris Johns:
> Hi,
>
> I have been working on migrating covoar in the rtems-tools
repo to DWARF. The
> goal is remove objdump parsing and to get accurate details
about the functions
> being covered. This is an unfunded task.
>
> The work has resulted in a close examination of inlined code
in RTEMS and what I
> saw alarmed me so I have added a report to the rtems-exeinfo
tool in rtems-tools
> (the change is to be posted for review once I get the
coverage tests running).
>
> A summary report for hello.exe on RTEMS 5 for SPARC is:
>
> inlined funcs   : 1412
>     total funcs : 1956
>  % inline funcs : 72%
>      total size : 174616
>     inline size : 81668
>   % inline size : 46%
>
> This is a small application so it could be argued that skews
the figures. A
> large C/C++ application built with -O2 running on RTEMS 4.11
ARM reports the
> inline usage as:
>
> inlined funcs   : 10370
>     total funcs : 17700
>  % inline funcs : 58%
>      total size : 3066240
>     inline size : 1249514
>   % inline size : 40%
>
> This does not seem right to me.
>
> The report is new and there could be issues in the DWARF
handling that feeds
> this report however I am posting this to start a discussion
on the topic of
> inlining.
>
> I attach the report for hello.exe. The `-i` option generates
the inline report.
>
> The first section is a summary showing the total number of
functions in the
> executable that have machine code and are flagged as inline.
The report lists
> the percentage of functions that are inlined and the
percentage of machine code
> that is inlined. The values seem high to me.
>
> The second table lists inline functions that are repeated
sorted from the
> largest foot print to the smallest. The first column the
total size of machine
> code in the executable and the second column the number of
instances.
>
> The third table is the list of inline functions sorted from
largest machine code
> footprint to smallest. The second column are flags of which
there is one. A `E`
> indicates the inline function is also external which means
the compiler has
> created an external reference to this function, ie an
address-of is being taken.
> The third column is the address in the executable so you can
take a look with
> objdump at the machine code.
>
> We need to ask some important question in relation to
inlining. It is cheap to
> add and we all feel the code we add needs to be fast and
needs to be inlined but
> does it really need to be inlined?
>
> Some pieces of code do need to be inlined and the overhead
is just that an
> overhead, for example in the large C/C++ application there
is a low level
> volatile hardware write routing with close to 300 instances
and a code size of
> 10K. This code needs to be inlined for performance reasons
but should the size
> on average be 40 bytes, I doubt it.
>
> Can we be more judicious with our use of the inline keyword?
>
> Is the performance gain we really expect or is the actual
overhead of a call
> frame not worth saving?
>
> What are the real costs of inlining a piece of code? It adds
size to the
> executable and depending on the code being inlined it
complicates coverage
> analysis be adding extra branch points.
>
> The metrics to determine what should be inlined is
complicated and I do not
> think we have a suitable policy in place. I believe it is
time we to create one.
>
> The issue is not limited to our code, gcc, newlib and
libstdc++ seem to have
> some code that should be looked at more closely. For example
__udivmoddi4, and
> __sprint_r.
>
> Chris
>
>

 Hello Chris,

 I just took a look at one of the first function in your list:
__sprint_r

Re: [PATCH] rfs: Remove erroneous call of rtems_disk_release()

[Chris Johns]

On 07/08/2018 15:30, Sebastian Huber wrote:
> 
> Since multiple milestones per ticket are unrealistic in Trac and what you 
> wrote
> above I think this plug-in is still useful:
> 
> https://trac.edgewall.org/wiki/TicketClone
> 
> The basic work flow is:
> 
> 1. Add a ticket for the master.
> 
> 2. Clone it for every branch the bug is applicable and adjust the milestone
> accordingly.
> 

That is a good idea. I will ping Amar tomorrow. I do not touch the Trac install.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] rfs: Remove erroneous call of rtems_disk_release()

[Sebastian Huber]

On 07/08/18 03:18, Chris Johns wrote:

On 06/08/2018 23:21, Sebastian Huber wrote:

On 06/08/18 15:03, Joel Sherrill wrote:

On Mon, Aug 6, 2018, 3:01 AM Sebastian Huber
mailto:sebastian.hu...@embedded-brains.de>> wrote:

     On 06/08/18 09:47, Chris Johns wrote:
     > On 06/08/2018 16:13, Sebastian Huber wrote:
     >> this needs a back port to 4.11 and 4.10.
     >>
     > I saw the ticket for 4.10 and assumed the patch was for 4.10. We
     separate
     > tickets for each branch.

     This makes the ticket handling a bit more complicated. Why is this
     necessary? Are different tickets for the same bug really great? I
     think
     the rational is that if a bug is fixed in version x, then it is also
     fixed in all versions x + i.


It is a human assumption but it doesn't work out right for using Trac to
generate release reports. Each ticket has a single milestone. So it would be
fixed in 4.10.n but we don't know where along the 4.11 series it got fixed
based on Trac 4.11 release reports.

Creating an arbitrary number of tickets for one bug looks like a workaround for
a Trac or release note generator shortcoming. Each ticket should probably have a
list of milestones.

I am not so sure. I originally thought this a while back when I encountered the
same thing. I also looked around for add-ons for Trac to handle this and I could
not find one. I suspect the complexity at a database level of mapping this would
not be simple.


Yes, there seems to be some structural problem with this in Trac. At 
least this bug is open for 14 years:


https://trac.edgewall.org/ticket/221



A branch is an instance of RTEMS and each branch has it's own life cycle. A bug
report that extends across multiple branches would break that isolation. A
ticket may require extra work, other changes or something else and if the ticket
is shared across more than one branch the other branches would become polluted.

I see the release notes being generated from the Trac data as a really good
thing. It is making us ensure we follow a proper process.


There should be definitely some guideline for this since this was at least not
obvious to me.

Yes I agree.


Since multiple milestones per ticket are unrealistic in Trac and what 
you wrote above I think this plug-in is still useful:


https://trac.edgewall.org/wiki/TicketClone

The basic work flow is:

1. Add a ticket for the master.

2. Clone it for every branch the bug is applicable and adjust the 
milestone accordingly.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: How to Deal With Great SPARC Reference

[Sebastian Huber]

On 06/08/18 20:22, Joel Sherrill wrote:

Hi

For a long time I have had a bookmark with a link to someone's personal
website which had a great discussion of SPARC v8 registers, calls, 
register

windows, etc.  While looking for space on my bookmark bar, I realized this
one has been dead a while. I found it at archive.org .

https://web.archive.org/web/20120205014832/https://www.sics.se/~psm/sparcstack.html 



I think this is great reference information which could be incorporated
into the SPARC specific documentation we have. Of course, with
proper reference.

Anyone see any issue with using the material?


This page was definitely a big help for me to understand what is going 
on SPARC.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 01/21] ramdisk: Use rtems_blkdev_create()

[Chris Johns]

This patch series is a nice clean up. Thank you.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] rfs: Remove erroneous call of rtems_disk_release()

[Chris Johns]

On 06/08/2018 23:21, Sebastian Huber wrote:
> On 06/08/18 15:03, Joel Sherrill wrote:
>> On Mon, Aug 6, 2018, 3:01 AM Sebastian Huber
>> > > wrote:
>>
>>     On 06/08/18 09:47, Chris Johns wrote:
>>     > On 06/08/2018 16:13, Sebastian Huber wrote:
>>     >> this needs a back port to 4.11 and 4.10.
>>     >>
>>     > I saw the ticket for 4.10 and assumed the patch was for 4.10. We
>>     separate
>>     > tickets for each branch.
>>
>>     This makes the ticket handling a bit more complicated. Why is this
>>     necessary? Are different tickets for the same bug really great? I
>>     think
>>     the rational is that if a bug is fixed in version x, then it is also
>>     fixed in all versions x + i.
>>
>>
>> It is a human assumption but it doesn't work out right for using Trac to
>> generate release reports. Each ticket has a single milestone. So it would be
>> fixed in 4.10.n but we don't know where along the 4.11 series it got fixed
>> based on Trac 4.11 release reports.
> 
> Creating an arbitrary number of tickets for one bug looks like a workaround 
> for
> a Trac or release note generator shortcoming. Each ticket should probably 
> have a
> list of milestones.

I am not so sure. I originally thought this a while back when I encountered the
same thing. I also looked around for add-ons for Trac to handle this and I could
not find one. I suspect the complexity at a database level of mapping this would
not be simple.

A branch is an instance of RTEMS and each branch has it's own life cycle. A bug
report that extends across multiple branches would break that isolation. A
ticket may require extra work, other changes or something else and if the ticket
is shared across more than one branch the other branches would become polluted.

I see the release notes being generated from the Trac data as a really good
thing. It is making us ensure we follow a proper process.

> There should be definitely some guideline for this since this was at least not
> obvious to me.

Yes I agree.

> Chris used the blocked by field to link such tickets:
> 
> https://devel.rtems.org/ticket/3323
> 

I did this to make sure I knew which tickets are part of the same task.

> I used update commits in the past and a close commit for the first milestone, 
> e.g.
> 
> https://devel.rtems.org/ticket/2622

I have done similar things. We are improving how we work.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Inlined code

[Chris Johns]

On 07/08/2018 05:14, Joel Sherrill wrote:
> 
> On Mon, Aug 6, 2018 at 1:21 AM, Chris Johns  > wrote:
> 
> On 06/08/2018 16:12, Christian Mauderer wrote:
> > Am 06.08.2018 um 07:31 schrieb Chris Johns:
> >> On 06/08/2018 10:51, Chris Johns wrote:
> >>> On 05/08/2018 19:39, Christian Mauderer wrote:
>  Am 05.08.2018 um 04:00 schrieb Chris Johns:
> > Hi,
> >
> > I have been working on migrating covoar in the rtems-tools repo to
> DWARF. The
> > goal is remove objdump parsing and to get accurate details about the
> functions
> > being covered. This is an unfunded task.
> >
> > The work has resulted in a close examination of inlined code in 
> RTEMS
> and what I
> > saw alarmed me so I have added a report to the rtems-exeinfo tool in
> rtems-tools
> > (the change is to be posted for review once I get the coverage tests
> running).
> >
> > A summary report for hello.exe on RTEMS 5 for SPARC is:
> >
> > inlined funcs   : 1412
> >     total funcs : 1956
> >  % inline funcs : 72%
> >      total size : 174616
> >     inline size : 81668
> >   % inline size : 46%
> >
> > This is a small application so it could be argued that skews the
> figures. A
> > large C/C++ application built with -O2 running on RTEMS 4.11 ARM
> reports the
> > inline usage as:
> >
> > inlined funcs   : 10370
> >     total funcs : 17700
> >  % inline funcs : 58%
> >      total size : 3066240
> >     inline size : 1249514
> >   % inline size : 40%
> >
> > This does not seem right to me.
> >
> > The report is new and there could be issues in the DWARF handling 
> that
> feeds
> > this report however I am posting this to start a discussion on the
> topic of
> > inlining.
> >
> > I attach the report for hello.exe. The `-i` option generates the
> inline report.
> >
> > The first section is a summary showing the total number of functions
> in the
> > executable that have machine code and are flagged as inline. The
> report lists
> > the percentage of functions that are inlined and the percentage of
> machine code
> > that is inlined. The values seem high to me.
> >
> > The second table lists inline functions that are repeated sorted 
> from the
> > largest foot print to the smallest. The first column the total size 
> of
> machine
> > code in the executable and the second column the number of 
> instances.
> >
> > The third table is the list of inline functions sorted from largest
> machine code
> > footprint to smallest. The second column are flags of which there is
> one. A `E`
> > indicates the inline function is also external which means the
> compiler has
> > created an external reference to this function, ie an address-of is
> being taken.
> > The third column is the address in the executable so you can take a
> look with
> > objdump at the machine code.
> >
> > We need to ask some important question in relation to inlining. It 
> is
> cheap to
> > add and we all feel the code we add needs to be fast and needs to be
> inlined but
> > does it really need to be inlined?
> >
> > Some pieces of code do need to be inlined and the overhead is just 
> that an
> > overhead, for example in the large C/C++ application there is a low 
> level
> > volatile hardware write routing with close to 300 instances and a 
> code
> size of
> > 10K. This code needs to be inlined for performance reasons but 
> should
> the size
> > on average be 40 bytes, I doubt it.
> >
> > Can we be more judicious with our use of the inline keyword?
> >
> > Is the performance gain we really expect or is the actual overhead 
> of
> a call
> > frame not worth saving?
> >
> > What are the real costs of inlining a piece of code? It adds size 
> to the
> > executable and depending on the code being inlined it complicates 
> coverage
> > analysis be adding extra branch points.
> >
> > The metrics to determine what should be inlined is complicated and I
> do not
> > think we have a suitable policy in place. I believe it is time we to
> create one.
> >
> > The issue is not limited to our code, gcc, newlib and libstdc++ seem
> to have
> > some code that should be looked at more closely. For example
> __udivmoddi4, and
> > __sprint_r.
> >
> > Chris
> >
> >
> 
>  Hello 

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

[Chris Johns]

On 07/08/2018 09:27, Joel Sherrill wrote:
> On Mon, Aug 6, 2018 at 8:13 AM, Amaan Cheval  > wrote:
> 
> Thanks for all the help! I have a simple test using the RTEMS
> interrupt manager working successfully (tested by calling
> rtems_interrupt_handler_install for vector 0, and then triggering a
> divide-by-0 exception).
> 
> Yeah! 
> 
> Could someone shed any light on why the i386 only hooks the first 17
> vectors as "RTEMS interrupts"?
> 
> You are making me feel very old especially since I have the real
> IBM manual in my office which corresponds to the answer.

Grandchildren, grey hair or Sebastian posting he is feeling old do not make you
feel old? Interesting! ;) :)

> It is dated Sept 1985. In fairness, I saved it from the garbage heap
> years later when someone was cleaning out their office. :)

Ah the good old days before the internet and search engines!!

> The x86 architecture is really vectored and the original i386
> port actually used simple direct vectoring since the first BSP wasn't
> a PC. Imagine that!  Another board using an i386 which didn't
> look like a PC at all. 
> 
> For better or worse, the PC/AT (286) and later used two i8259 PICs 
> in a master and slave configuration. The slave PIC cascaded off the 
> master PIC. This all fed into one CPU IRQ so many of the direct
> vectors were unused. The PIC arrangement is described here:
> 
> https://en.wikipedia.org/wiki/Interrupt_request_(PC_architecture)
> 
> Here's what I'm aiming to get done before the GSoC deadline:
> 
> - Remap PIC (masking/disabling the PIC doesn't stop it from generating
> spurious interrupts (IRQ7), which would look like exceptions to us)
> - Disable PIC
> - Enable APIC (done already, but confirm it plays well with the recent
> changes to the IDT)
> - Enable the PIT timer and use it to calibrate the APIC timer
> - Clock driver using the APIC timer - (1) generate interrupts on ticks
> and (2) tc_get_timecount function which calculates total time passed
> through calculating (number of IRQs occured * time_per_irq +
> time_passed_since_last_irq (through tick counter))
> 
> This does seem a bit ambitious given how short we are on time - I'll
> finish this up even after the deadline if need be.
> 
> What should our minimum deliverable be for this period? Should we try
> to upstream the interrupt support before I finish the clock driver? (I
> think we can have this discussion on Wednesday or so, since by then
> I'll likely know how much progress on the clock driver remains.)
> 
> We could but do you think it is likely to have major changes based 
> on getting the tick working?
> 
> Try to see what gets done and post what you can by the end of GSoC.
> 
> Then we will all wait patiently for you to get it working if it isn't then.

I think this BSP code in our repo is the best place for it to be worked on.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

[Joel Sherrill]

On Mon, Aug 6, 2018 at 8:13 AM, Amaan Cheval  wrote:

> Thanks for all the help! I have a simple test using the RTEMS
> interrupt manager working successfully (tested by calling
> rtems_interrupt_handler_install for vector 0, and then triggering a
> divide-by-0 exception).
>

Yeah!

>
> Could someone shed any light on why the i386 only hooks the first 17
> vectors as "RTEMS interrupts"?
>

You are making me feel very old especially since I have the real
IBM manual in my office which corresponds to the answer.
It is dated Sept 1985. In fairness, I saved it from the garbage heap
years later when someone was cleaning out their office. :)

The x86 architecture is really vectored and the original i386
port actually used simple direct vectoring since the first BSP wasn't
a PC. Imagine that!  Another board using an i386 which didn't
look like a PC at all.

For better or worse, the PC/AT (286) and later used two i8259 PICs
in a master and slave configuration. The slave PIC cascaded off the
master PIC. This all fed into one CPU IRQ so many of the direct
vectors were unused. The PIC arrangement is described here:

https://en.wikipedia.org/wiki/Interrupt_request_(PC_architecture)


>
> Here's what I'm aiming to get done before the GSoC deadline:
>
> - Remap PIC (masking/disabling the PIC doesn't stop it from generating
> spurious interrupts (IRQ7), which would look like exceptions to us)
> - Disable PIC
> - Enable APIC (done already, but confirm it plays well with the recent
> changes to the IDT)
> - Enable the PIT timer and use it to calibrate the APIC timer
> - Clock driver using the APIC timer - (1) generate interrupts on ticks
> and (2) tc_get_timecount function which calculates total time passed
> through calculating (number of IRQs occured * time_per_irq +
> time_passed_since_last_irq (through tick counter))
>
> This does seem a bit ambitious given how short we are on time - I'll
> finish this up even after the deadline if need be.
>
> What should our minimum deliverable be for this period? Should we try
> to upstream the interrupt support before I finish the clock driver? (I
> think we can have this discussion on Wednesday or so, since by then
> I'll likely know how much progress on the clock driver remains.)
>

We could but do you think it is likely to have major changes based
on getting the tick working?

Try to see what gets done and post what you can by the end of GSoC.

Then we will all wait patiently for you to get it working if it isn't then.

You do need to do a final report.


>
> Sorry about the rush near the deadline - getting the APIC functioning
> had a bunch more yak-shaving style issues than I anticipated.
>

The x86 architecture is years of hack upon hack.


>
> On Wed, Aug 1, 2018 at 10:51 PM, Joel Sherrill  wrote:
> > I have started to reply twice but you jumped in ahead. :)
> >
> > On Wed, Aug 1, 2018 at 12:12 PM, Amaan Cheval 
> > wrote:
> >>
> >> If my previous email _is_ in fact correct, could someone confirm?
> >> Because this excerpt in the documentation here seems to contradict it
> >> (which was what lead to the confusion in the first place):
> >>
> >>
> >> https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#
> establishing-an-isr
> >>
> >> With my emphasis:
> >>
> >> > The rtems_interrupt_catch directive establishes an ISR for the system.
> >> > The address of the ISR and its associated CPU vector number are
> specified to
> >> > this directive. This directive installs the **RTEMS interrupt wrapper
> in the
> >> > processor’s Interrupt Vector Table and the address of the user’s ISR
> in the
> >> > RTEMS’ Vector Table**. This directive returns the previous contents
> of the
> >> > specified vector in the RTEMS’ Vector Table.
> >
> >
> > Almost but Gedare and I left out a detail. rtems_interrupt_catch is ONLY
> > used on pure simple vectored architectures which do not use the
> > bsp_interrupt_*
> > or  interfaces. Some embedded MCUs are so simple and have
> > plenty of vectors so you don't need the complexity of supporting a PIC.
> For
> > example, the m68k family had 256 direct vectors and I don't recall ever
> > seeing
> > a PIC.[1]
> >
> > You should assume that you can ignore rtems_interrupt_catch and simple
> > vectored support for x86_64. See cpukit/rtems/intrcatch.c and I hope you
> > see an ifdef that results in the code disappearing on your port. Simple
> > vectored is FACE is your cpu.h. :)
> >
> > [1] Disclaimer: The support for the  interfaces is critical
> to
> > the
> > libbsd stack. We haven't discussed it but any architecture that is
> > sufficient
> > to run the new stack will have to support this interface. If someone
> wants
> > the
> > new stack on a 68040 VME board or a Coldfire board, we will have to find
> > the simplest, non-bloated way to support this. When doing the MIPS Malta,
> > we just converted the MIPS architecture away from simple vectored.
> >
> > So support the bsp_interrupt_* infrastructure. :)
> >
> > --joel
> >
> >>
> >>
> >> On 

Re: Inlined code

[Joel Sherrill]

On Mon, Aug 6, 2018 at 1:21 AM, Chris Johns  wrote:

> On 06/08/2018 16:12, Christian Mauderer wrote:
> > Am 06.08.2018 um 07:31 schrieb Chris Johns:
> >> On 06/08/2018 10:51, Chris Johns wrote:
> >>> On 05/08/2018 19:39, Christian Mauderer wrote:
>  Am 05.08.2018 um 04:00 schrieb Chris Johns:
> > Hi,
> >
> > I have been working on migrating covoar in the rtems-tools repo to
> DWARF. The
> > goal is remove objdump parsing and to get accurate details about the
> functions
> > being covered. This is an unfunded task.
> >
> > The work has resulted in a close examination of inlined code in
> RTEMS and what I
> > saw alarmed me so I have added a report to the rtems-exeinfo tool in
> rtems-tools
> > (the change is to be posted for review once I get the coverage tests
> running).
> >
> > A summary report for hello.exe on RTEMS 5 for SPARC is:
> >
> > inlined funcs   : 1412
> > total funcs : 1956
> >  % inline funcs : 72%
> >  total size : 174616
> > inline size : 81668
> >   % inline size : 46%
> >
> > This is a small application so it could be argued that skews the
> figures. A
> > large C/C++ application built with -O2 running on RTEMS 4.11 ARM
> reports the
> > inline usage as:
> >
> > inlined funcs   : 10370
> > total funcs : 17700
> >  % inline funcs : 58%
> >  total size : 3066240
> > inline size : 1249514
> >   % inline size : 40%
> >
> > This does not seem right to me.
> >
> > The report is new and there could be issues in the DWARF handling
> that feeds
> > this report however I am posting this to start a discussion on the
> topic of
> > inlining.
> >
> > I attach the report for hello.exe. The `-i` option generates the
> inline report.
> >
> > The first section is a summary showing the total number of functions
> in the
> > executable that have machine code and are flagged as inline. The
> report lists
> > the percentage of functions that are inlined and the percentage of
> machine code
> > that is inlined. The values seem high to me.
> >
> > The second table lists inline functions that are repeated sorted
> from the
> > largest foot print to the smallest. The first column the total size
> of machine
> > code in the executable and the second column the number of instances.
> >
> > The third table is the list of inline functions sorted from largest
> machine code
> > footprint to smallest. The second column are flags of which there is
> one. A `E`
> > indicates the inline function is also external which means the
> compiler has
> > created an external reference to this function, ie an address-of is
> being taken.
> > The third column is the address in the executable so you can take a
> look with
> > objdump at the machine code.
> >
> > We need to ask some important question in relation to inlining. It
> is cheap to
> > add and we all feel the code we add needs to be fast and needs to be
> inlined but
> > does it really need to be inlined?
> >
> > Some pieces of code do need to be inlined and the overhead is just
> that an
> > overhead, for example in the large C/C++ application there is a low
> level
> > volatile hardware write routing with close to 300 instances and a
> code size of
> > 10K. This code needs to be inlined for performance reasons but
> should the size
> > on average be 40 bytes, I doubt it.
> >
> > Can we be more judicious with our use of the inline keyword?
> >
> > Is the performance gain we really expect or is the actual overhead
> of a call
> > frame not worth saving?
> >
> > What are the real costs of inlining a piece of code? It adds size to
> the
> > executable and depending on the code being inlined it complicates
> coverage
> > analysis be adding extra branch points.
> >
> > The metrics to determine what should be inlined is complicated and I
> do not
> > think we have a suitable policy in place. I believe it is time we to
> create one.
> >
> > The issue is not limited to our code, gcc, newlib and libstdc++ seem
> to have
> > some code that should be looked at more closely. For example
> __udivmoddi4, and
> > __sprint_r.
> >
> > Chris
> >
> >
> 
>  Hello Chris,
> 
>  I just took a look at one of the first function in your list:
> __sprint_r
> 
>  https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.
> git;a=blob;f=newlib/libc/stdio/vfprintf.c;h=c4bf2dbe31da64462ecccec97c8e90
> 1e4ffadd44;hb=HEAD#l403
> 
>  As far as I can see, there is no explicit inline key word for that
>  function. So in that case, the compiler decided that it would be a
> good
>  idea to inline that function.
> >>>
> >>> Thanks and yes. At this point in time I cannot tell what is happening
> and I am
> >>> not sure 

How to Deal With Great SPARC Reference

[Joel Sherrill]

Hi

For a long time I have had a bookmark with a link to someone's personal
website which had a great discussion of SPARC v8 registers, calls, register
windows, etc.  While looking for space on my bookmark bar, I realized this
one has been dead a while. I found it at archive.org.

https://web.archive.org/web/20120205014832/https://www.
sics.se/~psm/sparcstack.html

I think this is great reference information which could be incorporated
into the SPARC specific documentation we have. Of course, with
proper reference.

Anyone see any issue with using the material?

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] rfs: Remove erroneous call of rtems_disk_release()

[Sebastian Huber]

On 06/08/18 15:03, Joel Sherrill wrote:



On Mon, Aug 6, 2018, 3:01 AM Sebastian Huber 
> wrote:


On 06/08/18 09:47, Chris Johns wrote:
> On 06/08/2018 16:13, Sebastian Huber wrote:
>> this needs a back port to 4.11 and 4.10.
>>
> I saw the ticket for 4.10 and assumed the patch was for 4.10. We
separate
> tickets for each branch.

This makes the ticket handling a bit more complicated. Why is this
necessary? Are different tickets for the same bug really great? I
think
the rational is that if a bug is fixed in version x, then it is also
fixed in all versions x + i.


It is a human assumption but it doesn't work out right for using Trac 
to generate release reports. Each ticket has a single milestone. So it 
would be fixed in 4.10.n but we don't know where along the 4.11 series 
it got fixed based on Trac 4.11 release reports.


Creating an arbitrary number of tickets for one bug looks like a 
workaround for a Trac or release note generator shortcoming. Each ticket 
should probably have a list of milestones.


There should be definitely some guideline for this since this was at 
least not obvious to me.


Chris used the blocked by field to link such tickets:

https://devel.rtems.org/ticket/3323

I used update commits in the past and a close commit for the first 
milestone, e.g.


https://devel.rtems.org/ticket/2622

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

[Amaan Cheval]

Thanks for all the help! I have a simple test using the RTEMS
interrupt manager working successfully (tested by calling
rtems_interrupt_handler_install for vector 0, and then triggering a
divide-by-0 exception).

Could someone shed any light on why the i386 only hooks the first 17
vectors as "RTEMS interrupts"?

Here's what I'm aiming to get done before the GSoC deadline:

- Remap PIC (masking/disabling the PIC doesn't stop it from generating
spurious interrupts (IRQ7), which would look like exceptions to us)
- Disable PIC
- Enable APIC (done already, but confirm it plays well with the recent
changes to the IDT)
- Enable the PIT timer and use it to calibrate the APIC timer
- Clock driver using the APIC timer - (1) generate interrupts on ticks
and (2) tc_get_timecount function which calculates total time passed
through calculating (number of IRQs occured * time_per_irq +
time_passed_since_last_irq (through tick counter))

This does seem a bit ambitious given how short we are on time - I'll
finish this up even after the deadline if need be.

What should our minimum deliverable be for this period? Should we try
to upstream the interrupt support before I finish the clock driver? (I
think we can have this discussion on Wednesday or so, since by then
I'll likely know how much progress on the clock driver remains.)

Sorry about the rush near the deadline - getting the APIC functioning
had a bunch more yak-shaving style issues than I anticipated.

On Wed, Aug 1, 2018 at 10:51 PM, Joel Sherrill  wrote:
> I have started to reply twice but you jumped in ahead. :)
>
> On Wed, Aug 1, 2018 at 12:12 PM, Amaan Cheval 
> wrote:
>>
>> If my previous email _is_ in fact correct, could someone confirm?
>> Because this excerpt in the documentation here seems to contradict it
>> (which was what lead to the confusion in the first place):
>>
>>
>> https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#establishing-an-isr
>>
>> With my emphasis:
>>
>> > The rtems_interrupt_catch directive establishes an ISR for the system.
>> > The address of the ISR and its associated CPU vector number are specified 
>> > to
>> > this directive. This directive installs the **RTEMS interrupt wrapper in 
>> > the
>> > processor’s Interrupt Vector Table and the address of the user’s ISR in the
>> > RTEMS’ Vector Table**. This directive returns the previous contents of the
>> > specified vector in the RTEMS’ Vector Table.
>
>
> Almost but Gedare and I left out a detail. rtems_interrupt_catch is ONLY
> used on pure simple vectored architectures which do not use the
> bsp_interrupt_*
> or  interfaces. Some embedded MCUs are so simple and have
> plenty of vectors so you don't need the complexity of supporting a PIC. For
> example, the m68k family had 256 direct vectors and I don't recall ever
> seeing
> a PIC.[1]
>
> You should assume that you can ignore rtems_interrupt_catch and simple
> vectored support for x86_64. See cpukit/rtems/intrcatch.c and I hope you
> see an ifdef that results in the code disappearing on your port. Simple
> vectored is FACE is your cpu.h. :)
>
> [1] Disclaimer: The support for the  interfaces is critical to
> the
> libbsd stack. We haven't discussed it but any architecture that is
> sufficient
> to run the new stack will have to support this interface. If someone wants
> the
> new stack on a 68040 VME board or a Coldfire board, we will have to find
> the simplest, non-bloated way to support this. When doing the MIPS Malta,
> we just converted the MIPS architecture away from simple vectored.
>
> So support the bsp_interrupt_* infrastructure. :)
>
> --joel
>
>>
>>
>> On Wed, Aug 1, 2018 at 10:39 PM, Amaan Cheval 
>> wrote:
>> > Okay, I think I understand finally. Sorry about the rambling!
>> >
>> > When rtems_interrupt_catch is called, that's installing a "raw" ISR by
>> > modifying the processor specific table itself, so _ISR_Handler is
>> > never called, but the user ISR is.
>> >
>> > When rtems_interrupt_handler_install is called, that's an "RTEMS
>> > interrupt", and we go through the _ISR_Handler -> dispatch route I
>> > laid out earlier, leading to eventually the user's ISR.
>> >
>> > Thank you for letting me rubber-duck with you, everyone (let me know
>> > if anything above sounds off, though!) :P
>> >
>> > On Wed, Aug 1, 2018 at 10:20 PM, Amaan Cheval 
>> > wrote:
>> >> Thanks for the background!
>> >>
>> >> Let's use the gen5200 as the ongoing example - my confusion arises
>> >> here (correct me if any of the following points is incorrect!). In
>> >> overly simplified call chains:
>> >>
>> >> Register interrupt handler:
>> >> -  bsp_interrupt_facility_initialize() -> ppc_exc_set_handler(vec,
>> >> C_dispatch_irq_handler) -> ppc_exc_handler_table[vec] =
>> >> C_dispatch_irq_handler
>> >>
>> >> Interrupt handler called:
>> >> - C_dispatch_irq_handler -> dispatch -> bsp_interrupt_handler_dispatch
>> >> (irq-generic.h) -> bsp_interrupt_handler_table[index].handler()
>> >>
>> >> What I'm confused about is how 

Re: [PATCH] rfs: Remove erroneous call of rtems_disk_release()

[Joel Sherrill]

On Mon, Aug 6, 2018, 3:01 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 06/08/18 09:47, Chris Johns wrote:
> > On 06/08/2018 16:13, Sebastian Huber wrote:
> >> this needs a back port to 4.11 and 4.10.
> >>
> > I saw the ticket for 4.10 and assumed the patch was for 4.10. We separate
> > tickets for each branch.
>
> This makes the ticket handling a bit more complicated. Why is this
> necessary? Are different tickets for the same bug really great? I think
> the rational is that if a bug is fixed in version x, then it is also
> fixed in all versions x + i.
>

It is a human assumption but it doesn't work out right for using Trac to
generate release reports. Each ticket has a single milestone. So it would
be fixed in 4.10.n but we don't know where along the 4.11 series it got
fixed based on Trac 4.11 release reports.

--joel

>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] score: Fix _Addresses_Subtract()

[Sebastian Huber]

Use architecture-specific integer type for an address difference.

Update #3486.
---
 cpukit/include/rtems/rtems/partimpl.h | 4 ++--
 cpukit/include/rtems/score/address.h  | 9 +++--
 cpukit/rtems/src/dpmemexternal2internal.c | 8 
 cpukit/rtems/src/dpmeminternal2external.c | 8 
 4 files changed, 13 insertions(+), 16 deletions(-)

diff --git a/cpukit/include/rtems/rtems/partimpl.h 
b/cpukit/include/rtems/rtems/partimpl.h
index ff857708f0..02d3ff8b44 100644
--- a/cpukit/include/rtems/rtems/partimpl.h
+++ b/cpukit/include/rtems/rtems/partimpl.h
@@ -77,9 +77,9 @@ RTEMS_INLINE_ROUTINE bool _Partition_Is_buffer_on_boundary (
   Partition_Control *the_partition
 )
 {
-  uint32_t offset;
+  intptr_t offset;
 
-  offset = (uint32_t) _Addresses_Subtract(
+  offset = _Addresses_Subtract(
 the_buffer,
 the_partition->starting_address
   );
diff --git a/cpukit/include/rtems/score/address.h 
b/cpukit/include/rtems/score/address.h
index 8f38f7c2dc..fb88230d18 100644
--- a/cpukit/include/rtems/score/address.h
+++ b/cpukit/include/rtems/score/address.h
@@ -77,7 +77,7 @@ RTEMS_INLINE_ROUTINE void *_Addresses_Subtract_offset (
 }
 
 /**
- * @brief Subtract two offsets.
+ * @brief Subtract two addresses.
  *
  * This function is used to subtract two addresses.  It returns the
  * resulting offset.
@@ -86,16 +86,13 @@ RTEMS_INLINE_ROUTINE void *_Addresses_Subtract_offset (
  * @param[in] right is the address on the right hand side of the subtraction.
  *
  * @return This method returns the resulting address.
- *
- * @note  The cast of an address to an uint32_t makes this code
- *dependent on an addresses being thirty two bits.
  */
-RTEMS_INLINE_ROUTINE int32_t _Addresses_Subtract (
+RTEMS_INLINE_ROUTINE intptr_t _Addresses_Subtract(
   const void *left,
   const void *right
 )
 {
-  return (int32_t) ((const char *) left - (const char *) right);
+  return (intptr_t) ( (const char *) left - (const char *) right );
 }
 
 /**
diff --git a/cpukit/rtems/src/dpmemexternal2internal.c 
b/cpukit/rtems/src/dpmemexternal2internal.c
index 0456010675..0d9a754b23 100644
--- a/cpukit/rtems/src/dpmemexternal2internal.c
+++ b/cpukit/rtems/src/dpmemexternal2internal.c
@@ -29,7 +29,7 @@ rtems_status_code rtems_port_external_to_internal(
 {
   Dual_ported_memory_Control *the_port;
   ISR_lock_Contextlock_context;
-  uint32_tending;
+  uintptr_t   length;
 
   if ( internal == NULL ) {
 return RTEMS_INVALID_ADDRESS;
@@ -41,12 +41,12 @@ rtems_status_code rtems_port_external_to_internal(
 return RTEMS_INVALID_ID;
   }
 
-  ending = _Addresses_Subtract( external, the_port->external_base );
+  length = (uintptr_t) _Addresses_Subtract( external, the_port->external_base 
);
 
-  if ( ending > the_port->length ) {
+  if ( length > the_port->length ) {
 *internal = external;
   } else {
-*internal = _Addresses_Add_offset( the_port->internal_base, ending );
+*internal = _Addresses_Add_offset( the_port->internal_base, length );
   }
 
   _ISR_lock_ISR_enable( _context );
diff --git a/cpukit/rtems/src/dpmeminternal2external.c 
b/cpukit/rtems/src/dpmeminternal2external.c
index bd66ee45cb..9cd1a5d2f8 100644
--- a/cpukit/rtems/src/dpmeminternal2external.c
+++ b/cpukit/rtems/src/dpmeminternal2external.c
@@ -29,7 +29,7 @@ rtems_status_code rtems_port_internal_to_external(
 {
   Dual_ported_memory_Control *the_port;
   ISR_lock_Contextlock_context;
-  uint32_tending;
+  uintptr_t   length;
 
   if ( external == NULL ) {
 return RTEMS_INVALID_ADDRESS;
@@ -41,12 +41,12 @@ rtems_status_code rtems_port_internal_to_external(
 return RTEMS_INVALID_ID;
   }
 
-  ending = _Addresses_Subtract( internal, the_port->internal_base );
+  length = (uintptr_t) _Addresses_Subtract( internal, the_port->internal_base 
);
 
-  if ( ending > the_port->length ) {
+  if ( length > the_port->length ) {
 *external = internal;
   } else {
-*external = _Addresses_Add_offset( the_port->external_base, ending );
+*external = _Addresses_Add_offset( the_port->external_base, length );
   }
 
   _ISR_lock_ISR_enable( _context );
-- 
2.13.7

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] bsp/atsam: Fix handling of slow SPI speeds.

[Christian Mauderer]

This patch fixes an overflow in the frequency calculation of the SPI
driver for slow SPI speeds.
---
 bsps/arm/atsam/spi/atsam_spi_bus.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/bsps/arm/atsam/spi/atsam_spi_bus.c 
b/bsps/arm/atsam/spi/atsam_spi_bus.c
index 35f44f525d..b40fa56f7a 100644
--- a/bsps/arm/atsam/spi/atsam_spi_bus.c
+++ b/bsps/arm/atsam/spi/atsam_spi_bus.c
@@ -85,6 +85,23 @@ static uint8_t atsam_calculate_dlybcs(uint16_t delay_in_us)
 (BOARD_MCK / delay_in_us) : 0xFF;
 }
 
+static uint32_t atsam_calculate_scbr(uint32_t speed_hz)
+{
+  uint32_t scbr;
+
+  scbr = BOARD_MCK / speed_hz;
+  if (scbr > 0x0FF) {
+/* Best estimation we can offer with the hardware. */
+scbr = 0x0FF;
+  }
+  if (scbr == 0) {
+/* SCBR = 0 isn't allowed. */
+scbr = 1;
+  }
+
+  return scbr;
+}
+
 static void atsam_set_phase_and_polarity(uint32_t mode, uint32_t *csr)
 {
   uint32_t mode_mask = mode & SPI_MODE_3;
@@ -109,11 +126,13 @@ static void atsam_set_phase_and_polarity(uint32_t mode, 
uint32_t *csr)
 static void atsam_configure_spi(atsam_spi_bus *bus)
 {
   uint8_t delay_cs;
+  uint32_t scbr;
   uint32_t csr = 0;
   uint32_t mode = 0;
   uint32_t cs = bus->base.cs;
 
   delay_cs = atsam_calculate_dlybcs(bus->base.delay_usecs);
+  scbr = atsam_calculate_scbr(bus->base.speed_hz);
 
   mode |= SPI_MR_DLYBCS(delay_cs);
   mode |= SPI_MR_MSTR;
@@ -137,7 +156,7 @@ static void atsam_configure_spi(atsam_spi_bus *bus)
   csr =
 SPI_DLYBCT(1000, BOARD_MCK) |
 SPI_DLYBS(1000, BOARD_MCK) |
-SPI_SCBR(bus->base.speed_hz, BOARD_MCK) |
+SPI_CSR_SCBR(scbr) |
 SPI_CSR_BITS(bus->base.bits_per_word - 8);
 
   atsam_set_phase_and_polarity(bus->base.mode, );
-- 
2.13.7

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] rfs: Remove erroneous call of rtems_disk_release()

[Sebastian Huber]

On 06/08/18 09:47, Chris Johns wrote:

On 06/08/2018 16:13, Sebastian Huber wrote:

this needs a back port to 4.11 and 4.10.


I saw the ticket for 4.10 and assumed the patch was for 4.10. We separate
tickets for each branch.


This makes the ticket handling a bit more complicated. Why is this 
necessary? Are different tickets for the same bug really great? I think 
the rational is that if a bug is fixed in version x, then it is also 
fixed in all versions x + i.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] rfs: Remove erroneous call of rtems_disk_release()

[Chris Johns]

On 06/08/2018 16:13, Sebastian Huber wrote:
> 
> this needs a back port to 4.11 and 4.10.
> 

I saw the ticket for 4.10 and assumed the patch was for 4.10. We separate
tickets for each branch.

Are you able to handle this or should I put it on the list?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 14/21] libtests/block15: Use rtems_blkdev_create()

[Sebastian Huber]

Update #3358.
---
 testsuites/libtests/block15/init.c | 42 ++
 1 file changed, 24 insertions(+), 18 deletions(-)

diff --git a/testsuites/libtests/block15/init.c 
b/testsuites/libtests/block15/init.c
index cf9ec5fc0c..925a772842 100644
--- a/testsuites/libtests/block15/init.c
+++ b/testsuites/libtests/block15/init.c
@@ -18,11 +18,14 @@
 
 #include "tmacros.h"
 
+#include 
+#include 
 #include 
-#include 
+#include 
 #include 
+#include 
+#include 
 
-#include 
 #include 
 
 const char rtems_test_name[] = "BLOCK 15";
@@ -41,6 +44,8 @@ const char rtems_test_name[] = "BLOCK 15";
 
 #define BLOCK_SIZE 4
 
+#define DISK_PATH "/disk"
+
 static const rtems_blkdev_bnum action_sequence [ACTION_COUNT] = {
   2, 1, 0, 4, 5, 6, 7, 9
 };
@@ -90,8 +95,7 @@ static int test_disk_ioctl(rtems_disk_device *dd, uint32_t 
req, void *arg)
   } else if (req == RTEMS_BLKIO_CAPABILITIES) {
 *(uint32_t *) arg = RTEMS_BLKDEV_CAP_MULTISECTOR_CONT;
   } else {
-errno = EINVAL;
-rv = -1;
+rv = rtems_blkdev_ioctl(dd, req, arg);
   }
 
   return rv;
@@ -126,32 +130,32 @@ static void test_write_requests(rtems_disk_device *dd)
 static void test(void)
 {
   rtems_status_code sc;
-  dev_t dev = 0;
   rtems_disk_device *dd;
+  int fd;
+  int rv;
 
-  sc = rtems_disk_io_initialize();
-  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
-
-  sc = rtems_disk_create_phys(
-dev,
+  sc = rtems_blkdev_create(
+DISK_PATH,
 MEDIA_BLOCK_SIZE,
 BLOCK_COUNT,
 test_disk_ioctl,
-NULL,
 NULL
   );
   rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 
-  dd = rtems_disk_obtain(dev);
-  rtems_test_assert(dd != NULL);
+  fd = open(DISK_PATH, O_RDWR);
+  rtems_test_assert(fd >= 0);
 
-  test_write_requests(dd);
+  rv = rtems_disk_fd_get_disk_device(fd, );
+  rtems_test_assert(rv == 0);
 
-  sc = rtems_disk_release(dd);
-  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+  rv = close(fd);
+  rtems_test_assert(rv == 0);
 
-  sc = rtems_disk_delete(dev);
-  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+  test_write_requests(dd);
+
+  rv = unlink(DISK_PATH);
+  rtems_test_assert(rv == 0);
 }
 
 static void Init(rtems_task_argument arg)
@@ -169,6 +173,8 @@ static void Init(rtems_task_argument arg)
 #define CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER
 #define CONFIGURE_APPLICATION_NEEDS_LIBBLOCK
 
+#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 4
+
 #define CONFIGURE_BDBUF_BUFFER_MIN_SIZE 1
 #define CONFIGURE_BDBUF_BUFFER_MAX_SIZE 4
 #define CONFIGURE_BDBUF_CACHE_MEMORY_SIZE (BLOCK_COUNT * BLOCK_SIZE)
-- 
2.13.7

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 21/21] libblock: Add RTEMS_DEPRECATED

[Sebastian Huber]

Close #3358.
---
 cpukit/include/rtems/blkdev.h  |  46 
 cpukit/include/rtems/diskdevs.h| 144 -
 cpukit/libblock/src/blkdev-imfs.c  |  13 ++--
 cpukit/libblock/src/blkdev-ops.c   |   2 +
 cpukit/libblock/src/blkdev.c   |   2 +
 cpukit/libblock/src/diskdevs.c |   2 +
 testsuites/libtests/block01/init.c |   2 +
 testsuites/libtests/block11/init.c |   7 +-
 8 files changed, 62 insertions(+), 156 deletions(-)

diff --git a/cpukit/include/rtems/blkdev.h b/cpukit/include/rtems/blkdev.h
index 929cf4fc24..31467a4142 100644
--- a/cpukit/include/rtems/blkdev.h
+++ b/cpukit/include/rtems/blkdev.h
@@ -387,70 +387,48 @@ void rtems_blkstats(
   rtems_blkdev_generic_write, \
   rtems_blkdev_generic_ioctl
 
-/**
- * Generic block device read primitive.
- *
- * Implemented using block device buffer management primitives.
- */
-rtems_device_driver
+/* Use rtems_blkdev_create() instead */
+RTEMS_DEPRECATED rtems_device_driver
 rtems_blkdev_generic_read(
 rtems_device_major_number major,
 rtems_device_minor_number minor,
 void* arg
 );
 
-/**
- * Generic block device write primitive.
- *
- * Implemented using block device buffer management primitives.
- */
-rtems_device_driver
+/* Use rtems_blkdev_create() instead */
+RTEMS_DEPRECATED rtems_device_driver
 rtems_blkdev_generic_write(
 rtems_device_major_number major,
 rtems_device_minor_number minor,
 void* arg
 );
 
-/**
- * Generic block device open primitive.
- *
- * Implemented using block device buffer management primitives.
- */
-rtems_device_driver
+/* Use rtems_blkdev_create() instead */
+RTEMS_DEPRECATED rtems_device_driver
 rtems_blkdev_generic_open(
 rtems_device_major_number major,
 rtems_device_minor_number minor,
 void* arg
 );
 
-/**
- * Generic block device close primitive.
- *
- * Implemented using block device buffer management primitives.
- */
-rtems_device_driver
+/* Use rtems_blkdev_create() instead */
+RTEMS_DEPRECATED rtems_device_driver
 rtems_blkdev_generic_close(
 rtems_device_major_number major,
 rtems_device_minor_number minor,
 void* arg
 );
 
-/**
- * Generic block device IO control primitive.
- *
- * Implemented using block device buffer management primitives.
- */
-rtems_device_driver
+/* Use rtems_blkdev_create() instead */
+RTEMS_DEPRECATED rtems_device_driver
 rtems_blkdev_generic_ioctl(
 rtems_device_major_number major,
 rtems_device_minor_number minor,
 void* arg
 );
 
-/**
- * @brief Generic block operations driver address table.
- */
-extern const rtems_driver_address_table rtems_blkdev_generic_ops;
+/* Use rtems_blkdev_create() instead */
+RTEMS_DEPRECATED extern const rtems_driver_address_table 
rtems_blkdev_generic_ops;
 
 /** @} */
 
diff --git a/cpukit/include/rtems/diskdevs.h b/cpukit/include/rtems/diskdevs.h
index 0be766afa3..85d157dcd5 100644
--- a/cpukit/include/rtems/diskdevs.h
+++ b/cpukit/include/rtems/diskdevs.h
@@ -277,21 +277,24 @@ struct rtems_disk_device {
  */
 /**@{**/
 
-static inline dev_t rtems_disk_get_device_identifier(
+/* Use fstat() instead */
+RTEMS_DEPRECATED static inline dev_t rtems_disk_get_device_identifier(
   const rtems_disk_device *dd
 )
 {
   return dd->dev;
 }
 
-static inline rtems_device_major_number rtems_disk_get_major_number(
+/* Use fstat() instead */
+RTEMS_DEPRECATED static inline rtems_device_major_number 
rtems_disk_get_major_number(
   const rtems_disk_device *dd
 )
 {
   return rtems_filesystem_dev_major_t(dd->dev);
 }
 
-static inline rtems_device_minor_number rtems_disk_get_minor_number(
+/* Use fstat() instead */
+RTEMS_DEPRECATED static inline rtems_device_minor_number 
rtems_disk_get_minor_number(
   const rtems_disk_device *dd
 )
 {
@@ -340,27 +343,8 @@ static inline rtems_blkdev_bnum rtems_disk_get_block_count(
  */
 /**@{**/
 
-/**
- * @brief Creates a physical disk with device identifier @a dev.
- *
- * The block size @a block_size must be positive.  The disk will have
- * @a block_count blocks.  The block index starts with zero.  The associated 
disk
- * device driver will be invoked via the IO control handler @a handler.  A
- * device node will be registered in the file system with absolute path @a
- * name, if @a name is not @c NULL.  This function is usually invoked from a
- * block device driver during initialization when a physical device is detected
- * in the system.  The device driver provides an IO control handler to allow
- * block device operations.
- *
- * @retval RTEMS_SUCCESSFUL Successful operation.
- * @retval RTEMS_NOT_CONFIGURED Cannot lock disk device operation mutex.
- * @retval RTEMS_INVALID_ADDRESS IO control handler is @c NULL.
- * @retval RTEMS_INVALID_NUMBER Block size is invalid.
- * @retval RTEMS_NO_MEMORY Not enough memory.
- * @retval RTEMS_RESOURCE_IN_USE Disk device descriptor is already in use.
- * @retval RTEMS_UNSATISFIED 

[PATCH 10/21] libtests/block10: Use rtems_blkdev_create()

[Sebastian Huber]

Update #3358.
---
 testsuites/libtests/block10/init.c | 69 --
 1 file changed, 28 insertions(+), 41 deletions(-)

diff --git a/testsuites/libtests/block10/init.c 
b/testsuites/libtests/block10/init.c
index 27c0bb5478..d5ac44ad53 100644
--- a/testsuites/libtests/block10/init.c
+++ b/testsuites/libtests/block10/init.c
@@ -7,12 +7,13 @@
  */
 
 /*
- * Copyright (c) 2010
- * embedded brains GmbH
- * Obere Lagerstr. 30
- * D-82178 Puchheim
- * Germany
- * 
+ * Copyright (c) 2010, 2018 embedded brains GmbH.
+ *
+ *   embedded brains GmbH
+ *   Dornierstr. 4
+ *   D-82178 Puchheim
+ *   Germany
+ *   
  *
  * The license and distribution terms for this file may be
  * found in the file LICENSE in this distribution or at
@@ -25,22 +26,19 @@
 
 #include "tmacros.h"
 
+#include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #include 
 #include 
-#include 
 #include 
 
-#include 
-
 const char rtems_test_name[] = "BLOCK 10";
 
-/* forward declarations to avoid warnings */
-static rtems_task Init(rtems_task_argument argument);
-
 #define ASSERT_SC(sc) assert((sc) == RTEMS_SUCCESSFUL)
 
 #define PRIORITY_HIGH 1
@@ -59,6 +57,8 @@ static rtems_task Init(rtems_task_argument argument);
 
 #define BLOCK_COUNT 1
 
+#define DISK_PATH "/disk"
+
 typedef rtems_bdbuf_buffer *(*access_func)(char task);
 
 typedef void (*release_func)(char task, rtems_bdbuf_buffer *bd);
@@ -71,11 +71,6 @@ static rtems_id task_id_purger;
 
 static rtems_id task_id_waiter;
 
-static const rtems_driver_address_table disk_ops = {
-  .initialization_entry = NULL,
-  RTEMS_GENERIC_BLOCK_DEVICE_DRIVER_ENTRIES
-};
-
 static void set_task_prio(rtems_id task, rtems_task_priority prio)
 {
   rtems_status_code sc = RTEMS_SUCCESSFUL;
@@ -121,34 +116,33 @@ static int disk_ioctl(rtems_disk_device *dd, uint32_t 
req, void *arg)
   }
 }
 
-static rtems_status_code disk_register(
+static void disk_register(
   uint32_t block_size,
   rtems_blkdev_bnum block_count,
-  dev_t *dev_ptr
+  rtems_disk_device **dd
 )
 {
   rtems_status_code sc = RTEMS_SUCCESSFUL;
-  rtems_device_major_number major = 0;
-  dev_t dev = 0;
-
-  sc = rtems_io_register_driver(0, _ops, );
-  ASSERT_SC(sc);
+  int fd;
+  int rv;
 
-  dev = rtems_filesystem_make_dev_t(major, 0);
-
-  sc = rtems_disk_create_phys(
-dev,
+  sc = rtems_blkdev_create(
+DISK_PATH,
 block_size,
 block_count,
 disk_ioctl,
-NULL,
 NULL
   );
   ASSERT_SC(sc);
 
-  *dev_ptr = dev;
+  fd = open(DISK_PATH, O_RDWR);
+  rtems_test_assert(fd >= 0);
+
+  rv = rtems_disk_fd_get_disk_device(fd, dd);
+  rtems_test_assert(rv == 0);
 
-  return RTEMS_SUCCESSFUL;
+  rv = close(fd);
+  rtems_test_assert(rv == 0);
 }
 
 static rtems_bdbuf_buffer *do_get(char task)
@@ -398,7 +392,6 @@ static const char *purger_assoc_table [PURGER_COUNT] = {
 static rtems_task Init(rtems_task_argument argument)
 {
   rtems_status_code sc = RTEMS_SUCCESSFUL;
-  dev_t dev = 0;
   size_t i_w = 0;
   size_t i_ac = 0;
   size_t i_rel = 0;
@@ -408,14 +401,7 @@ static rtems_task Init(rtems_task_argument argument)
 
   task_id_init = rtems_task_self();
 
-  sc = rtems_disk_io_initialize();
-  ASSERT_SC(sc);
-
-  sc = disk_register(BLOCK_SIZE, BLOCK_COUNT, );
-  ASSERT_SC(sc);
-
-  dd = rtems_disk_obtain(dev);
-  assert(dd != NULL);
+  disk_register(BLOCK_SIZE, BLOCK_COUNT, );
 
   sc = rtems_task_create(
 rtems_build_name('P', 'U', 'R', 'G'),
@@ -479,8 +465,9 @@ static rtems_task Init(rtems_task_argument argument)
 #define CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER
 #define CONFIGURE_APPLICATION_NEEDS_LIBBLOCK
 
+#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 4
+
 #define CONFIGURE_MAXIMUM_TASKS 3
-#define CONFIGURE_MAXIMUM_DRIVERS 4
 
 #define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
 
-- 
2.13.7

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 16/21] libchip/ata: Use rtems_blkdev_create()

[Sebastian Huber]

Update #3358.
---
 bsps/include/libchip/ata_internal.h |  2 --
 bsps/shared/dev/ide/ata.c   | 59 -
 2 files changed, 13 insertions(+), 48 deletions(-)

diff --git a/bsps/include/libchip/ata_internal.h 
b/bsps/include/libchip/ata_internal.h
index 985b6f597c..e977c91805 100644
--- a/bsps/include/libchip/ata_internal.h
+++ b/bsps/include/libchip/ata_internal.h
@@ -165,8 +165,6 @@ extern "C" {
  */
 #define ATA_REGISTERS_POSITION   0xfc
 
-#define ATA_MINOR_NUM_RESERVED_PER_ATA_DEVICE 64
-
 #define ATA_MAX_RTEMS_INT_VEC_NUMBER  255
 
 #define ATA_MAX_NAME_LENGTH   10
diff --git a/bsps/shared/dev/ide/ata.c b/bsps/shared/dev/ide/ata.c
index 7bb3f6ec73..fe2865fc90 100644
--- a/bsps/shared/dev/ide/ata.c
+++ b/bsps/shared/dev/ide/ata.c
@@ -18,7 +18,6 @@
 #include 
 #include  /* for "memset" declaration */
 
-#include 
 #include 
 #include 
 #include 
@@ -119,23 +118,17 @@ ata_add_to_controller_queue(rtems_device_minor_number  
ctrl_minor,
  * error occured
  */
 static rtems_status_code
-ata_io_data_request(dev_t device, rtems_blkdev_request *req)
+ata_io_data_request(ata_ide_dev_t *ata_dev, rtems_blkdev_request *req)
 {
 ata_req_t *areq; /* ATA request */
-rtems_device_minor_number  rel_minor; /* relative minor which indexes
-   * ata_devs array
-   */
 rtems_device_minor_number  ctrl_minor;
 uint8_tdev;
 
-rel_minor = (rtems_filesystem_dev_minor_t(device)) /
-ATA_MINOR_NUM_RESERVED_PER_ATA_DEVICE;
-
 /* get controller which serves the ATA device */
-ctrl_minor = ata_devs[rel_minor].ctrl_minor;
+ctrl_minor = ata_dev->ctrl_minor;
 
 /* get ATA device identifier (0 or 1) */
-dev = ata_devs[rel_minor].device;
+dev = ata_dev->device;
 
 areq = malloc(sizeof(ata_req_t));
 if (areq == NULL)
@@ -251,25 +244,19 @@ ata_io_data_request(dev_t device, rtems_blkdev_request 
*req)
  * error occured
  */
 static rtems_status_code
-ata_non_data_request(dev_t device, uint32_t cmd, void *argp)
+ata_non_data_request(ata_ide_dev_t *ata_dev, uint32_t cmd, void *argp)
 {
 rtems_status_code  rc;
 ata_req_t *areq;   /* ATA request */
-rtems_device_minor_number  rel_minor; /* relative minor which indexes
-   * ata_devs array
-   */
 rtems_device_minor_number  ctrl_minor;
 uint8_tdev;
 ata_queue_msg_tmsg;
 
-rel_minor = (rtems_filesystem_dev_minor_t(device)) /
-ATA_MINOR_NUM_RESERVED_PER_ATA_DEVICE;
-
 /* get controller which serves the ATA device */
-ctrl_minor = ata_devs[rel_minor].ctrl_minor;
+ctrl_minor = ata_dev->ctrl_minor;
 
 /* get ATA device identifier (0 or 1) */
-dev = ata_devs[rel_minor].device;
+dev = ata_dev->device;
 
 /* form the request */
 areq = malloc(sizeof(ata_req_t));
@@ -943,18 +930,14 @@ ata_queue_task(rtems_task_argument arg)
 static int
 ata_ioctl(rtems_disk_device *dd, uint32_t cmd, void *argp)
 {
-dev_t device = rtems_disk_get_device_identifier(dd);
-rtems_status_code status;
-rtems_device_minor_number rel_minor;
-
-rel_minor = (rtems_filesystem_dev_minor_t(device)) /
-ATA_MINOR_NUM_RESERVED_PER_ATA_DEVICE;
+ata_ide_dev_t *ata_dev = rtems_disk_get_driver_data(dd);
+rtems_status_code  status;
 
 /*
  * in most cases this means that device 'device' is not an registred ATA
  * device
  */
-if (ata_devs[rel_minor].device == ATA_UNDEFINED_VALUE)
+if (ata_dev->device == ATA_UNDEFINED_VALUE)
 {
 errno = ENODEV;
 return -1;
@@ -963,11 +946,11 @@ ata_ioctl(rtems_disk_device *dd, uint32_t cmd, void *argp)
 switch (cmd)
 {
 case RTEMS_BLKIO_REQUEST:
-status = ata_io_data_request(device, (rtems_blkdev_request *)argp);
+status = ata_io_data_request(ata_dev, (rtems_blkdev_request 
*)argp);
 break;
 
 case ATAIO_SET_MULTIPLE_MODE:
-status = ata_non_data_request(device, cmd, argp);
+status = ata_non_data_request(ata_dev, cmd, argp);
 break;
 
 case RTEMS_BLKIO_CAPABILITIES:
@@ -1102,7 +1085,6 @@ rtems_ata_initialize(rtems_device_major_number major,
 uint16_t  *buffer;
 inti, dev = 0;
 char   name[ATA_MAX_NAME_LENGTH];
-dev_t  device;
 ata_int_st_t  *int_st;
 
 #if CPU_SIMPLE_VECTORED_INTERRUPTS == TRUE
@@ -1114,11 +1096,6 @@ rtems_ata_initialize(rtems_device_major_number major,
 if (ata_initialized)
 return RTEMS_SUCCESSFUL;
 
-/* initialization of disk devices library */
-status = rtems_disk_io_initialize();
-if (status != 

[PATCH 20/21] fileio: Avoid deprecated rtems_disk_obtain()

[Sebastian Huber]

Update #3358.
---
 testsuites/samples/fileio/init.c | 47 +---
 1 file changed, 25 insertions(+), 22 deletions(-)

diff --git a/testsuites/samples/fileio/init.c b/testsuites/samples/fileio/init.c
index 6d30c41db0..f86593c46c 100644
--- a/testsuites/samples/fileio/init.c
+++ b/testsuites/samples/fileio/init.c
@@ -236,7 +236,7 @@ disk_test_set_block_size (rtems_disk_device *dd, size_t 
size)
 }
 
 static int
-disk_test_write_blocks (dev_t dev, int start, int count, size_t size)
+disk_test_write_blocks (const char *name, int start, int count, size_t size)
 {
   int block;
   uint32_t*   ip;
@@ -245,15 +245,27 @@ disk_test_write_blocks (dev_t dev, int start, int count, 
size_t size)
   rtems_bdbuf_buffer* bd;
   rtems_status_code   sc;
   int rv = 0;
-  rtems_disk_device* dd;
-  
-  dd = rtems_disk_obtain (dev);
-  if (!dd)
+  rtems_disk_device*  dd;
+  int fd;
+
+  fd = open(name, O_RDWR);
+  if (fd < 0) {
+printf ("error: cannot open disk\n");
+rv = 1;
+  }
+
+  if (rv == 0 && rtems_disk_fd_get_disk_device(fd, ) != 0)
   {
 printf ("error: cannot obtain disk\n");
 rv = 1;
   }
-  
+
+  if (fd >= 0 && close (fd) != 0)
+  {
+printf ("error: close disk failed\n");
+rv = 1;
+  }
+
   if (rv == 0 && disk_test_set_block_size (dd, size) < 0)
   {
 printf ("error: set block size failed: %s\n", strerror (errno));
@@ -285,20 +297,17 @@ disk_test_write_blocks (dev_t dev, int start, int count, 
size_t size)
 }
   }
 
-  rtems_disk_release (dd);
-
   return rv;
 }
 
 static int
 disk_test_block_sizes (int argc, char *argv[])
 {
-  struct stat st;
-  char*   name;
-  int start;
-  int count;
-  int size;
-  
+  char* name;
+  int   start;
+  int   count;
+  int   size;
+
   if (argc != (4 + 1))
   {
 printf ("error: need to supply a device path, start, block and size\n");
@@ -306,18 +315,12 @@ disk_test_block_sizes (int argc, char *argv[])
   }
 
   name = argv[1];
-  
-  if (stat (name, ) < 0)
-  {
-printf ("error: stat '%s' failed: %s\n", name, strerror (errno));
-return 1;
-  }
 
   start = strtoul (argv[2], 0, 0);
   count = strtoul (argv[3], 0, 0);
   size  = strtoul (argv[4], 0, 0);
-  
-  return disk_test_write_blocks (st.st_rdev, start, count, size);
+
+  return disk_test_write_blocks (name, start, count, size);
 }
 
 static uint32_t
-- 
2.13.7

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 12/21] libtests/block13: Use rtems_blkdev_create()

[Sebastian Huber]

Update #3358.
---
 testsuites/libtests/block13/init.c | 44 ++
 1 file changed, 25 insertions(+), 19 deletions(-)

diff --git a/testsuites/libtests/block13/init.c 
b/testsuites/libtests/block13/init.c
index afd7704026..0eb5d676ee 100644
--- a/testsuites/libtests/block13/init.c
+++ b/testsuites/libtests/block13/init.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (c) 2012 embedded brains GmbH.  All rights reserved.
+ * Copyright (c) 2012, 2018 embedded brains GmbH.  All rights reserved.
  *
  *  embedded brains GmbH
- *  Obere Lagerstr. 30
+ *  Dornierstr. 4
  *  82178 Puchheim
  *  Germany
  *  
@@ -18,10 +18,13 @@
 
 #include "tmacros.h"
 
+#include 
+#include 
 #include 
+#include 
 #include 
+#include 
 
-#include 
 #include 
 
 const char rtems_test_name[] = "BLOCK 13";
@@ -29,6 +32,8 @@ const char rtems_test_name[] = "BLOCK 13";
 #define BLOCK_COUNT 11
 #define READ_COUNT 23
 
+#define DISK_PATH "/disk"
+
 static int block_access_counts [BLOCK_COUNT];
 
 #define RESET_CACHE (-1)
@@ -130,8 +135,7 @@ static int test_disk_ioctl(rtems_disk_device *dd, uint32_t 
req, void *arg)
 
 rtems_blkdev_request_done(breq, RTEMS_SUCCESSFUL);
   } else {
-errno = EINVAL;
-rv = -1;
+rv = rtems_blkdev_ioctl(dd, req, arg);
   }
 
   return rv;
@@ -181,32 +185,32 @@ static void test_read_ahead(rtems_disk_device *dd)
 static void test(void)
 {
   rtems_status_code sc;
-  dev_t dev = 0;
   rtems_disk_device *dd;
+  int fd;
+  int rv;
 
-  sc = rtems_disk_io_initialize();
-  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
-
-  sc = rtems_disk_create_phys(
-dev,
+  sc = rtems_blkdev_create(
+DISK_PATH,
 1,
 BLOCK_COUNT,
 test_disk_ioctl,
-NULL,
 NULL
   );
   rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 
-  dd = rtems_disk_obtain(dev);
-  rtems_test_assert(dd != NULL);
+  fd = open(DISK_PATH, O_RDWR);
+  rtems_test_assert(fd >= 0);
 
-  test_read_ahead(dd);
+  rv = rtems_disk_fd_get_disk_device(fd, );
+  rtems_test_assert(rv == 0);
 
-  sc = rtems_disk_release(dd);
-  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+  rv = close(fd);
+  rtems_test_assert(rv == 0);
 
-  sc = rtems_disk_delete(dev);
-  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+  test_read_ahead(dd);
+
+  rv = unlink(DISK_PATH);
+  rtems_test_assert(rv == 0);
 }
 
 static void Init(rtems_task_argument arg)
@@ -224,6 +228,8 @@ static void Init(rtems_task_argument arg)
 #define CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER
 #define CONFIGURE_APPLICATION_NEEDS_LIBBLOCK
 
+#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 4
+
 #define CONFIGURE_BDBUF_BUFFER_MIN_SIZE 1
 #define CONFIGURE_BDBUF_BUFFER_MAX_SIZE 1
 #define CONFIGURE_BDBUF_CACHE_MEMORY_SIZE BLOCK_COUNT
-- 
2.13.7

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 19/21] dosfs: Avoid deprecated routine

[Sebastian Huber]

Update #3358.
---
 cpukit/libfs/src/dosfs/fat.c| 2 ++
 cpukit/libfs/src/dosfs/fat.h| 1 +
 cpukit/libfs/src/dosfs/msdos_dir.c  | 2 +-
 cpukit/libfs/src/dosfs/msdos_file.c | 2 +-
 4 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/cpukit/libfs/src/dosfs/fat.c b/cpukit/libfs/src/dosfs/fat.c
index 8701a21d9a..cb45f91efe 100644
--- a/cpukit/libfs/src/dosfs/fat.c
+++ b/cpukit/libfs/src/dosfs/fat.c
@@ -505,6 +505,8 @@ fat_init_volume_info(fat_fs_info_t *fs_info, const char 
*device)
 rtems_set_errno_and_return_minus_one(ENXIO);
 }
 
+vol->dev = stat_buf.st_dev;
+
 /* Read boot record */
 /* FIXME: Asserts FAT_MAX_BPB_SIZE < bdbuf block size */
 sc = rtems_bdbuf_read( vol->dd, 0, );
diff --git a/cpukit/libfs/src/dosfs/fat.h b/cpukit/libfs/src/dosfs/fat.h
index 4839cb7613..064b4747a9 100644
--- a/cpukit/libfs/src/dosfs/fat.h
+++ b/cpukit/libfs/src/dosfs/fat.h
@@ -331,6 +331,7 @@ typedef struct fat_vol_s
 uint8_tafat;   /* the number of active FAT */
 intfd; /* the disk device file descriptor */
 rtems_disk_device *dd; /* disk device (see libblock) */
+dev_t  dev;/* device identifier of disk */
 void  *private_data;   /* reserved */
 } fat_vol_t;
 
diff --git a/cpukit/libfs/src/dosfs/msdos_dir.c 
b/cpukit/libfs/src/dosfs/msdos_dir.c
index 535d5f56f0..a13caafa7e 100644
--- a/cpukit/libfs/src/dosfs/msdos_dir.c
+++ b/cpukit/libfs/src/dosfs/msdos_dir.c
@@ -383,7 +383,7 @@ msdos_dir_stat(
 
 msdos_fs_lock(fs_info);
 
-buf->st_dev = rtems_disk_get_device_identifier(fs_info->fat.vol.dd);
+buf->st_dev = fs_info->fat.vol.dev;
 buf->st_ino = fat_fd->ino;
 buf->st_mode  = S_IFDIR | S_IRWXU | S_IRWXG | S_IRWXO;
 buf->st_rdev = 0ll;
diff --git a/cpukit/libfs/src/dosfs/msdos_file.c 
b/cpukit/libfs/src/dosfs/msdos_file.c
index d7b170a01a..205631217f 100644
--- a/cpukit/libfs/src/dosfs/msdos_file.c
+++ b/cpukit/libfs/src/dosfs/msdos_file.c
@@ -130,7 +130,7 @@ msdos_file_stat(
 
 msdos_fs_lock(fs_info);
 
-buf->st_dev = rtems_disk_get_device_identifier(fs_info->fat.vol.dd);
+buf->st_dev = fs_info->fat.vol.dev;
 buf->st_ino = fat_fd->ino;
 buf->st_mode  = S_IFREG | S_IRWXU | S_IRWXG | S_IRWXO;
 buf->st_rdev = 0ll;
-- 
2.13.7

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 07/21] libtests/block06: Use rtems_blkdev_create()

[Sebastian Huber]

Update #3358.
---
 testsuites/libtests/block06/block06.scn | 820 
 testsuites/libtests/block06/init.c  | 234 -
 2 files changed, 499 insertions(+), 555 deletions(-)

diff --git a/testsuites/libtests/block06/block06.scn 
b/testsuites/libtests/block06/block06.scn
index c18724e30e..9606dd5b64 100644
--- a/testsuites/libtests/block06/block06.scn
+++ b/testsuites/libtests/block06/block06.scn
@@ -1,512 +1,516 @@
-*** TEST BLOCK 6 ***
-lower priority to 31: successful completion
-register disk driver
-disk io init: successful completion
+*** BEGIN OF TEST BLOCK 6 ***
+*** TEST VERSION: 5.0.0.0875607358b38443acf395ad675a4f07794d5f95
+*** TEST STATE: EXPECTED-PASS
+*** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API RTEMS_SMP
+*** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB 
6d9c77c77d271d1fc2dfe8493d6713930b52a6dd, Newlib 3.0.0)
+register disks
 disk init: /dev/bddisk0
-disk lock: successful completion
+disk lock: RTEMS_SUCCESSFUL
 disk init: /dev/bddisk1
-disk lock: successful completion
-creating task: bdt0: priority: 30: successful completion
-starting task: bdt0: successful completion
-creating task: bdt1: priority: 29: successful completion
-starting task: bdt1: successful completion
-creating task: bdt2: priority: 28: successful completion
-starting task: bdt2: successful completion
+disk lock: RTEMS_SUCCESSFUL
+lower priority to 31: RTEMS_SUCCESSFUL
+creating task: bdt0: priority: 30: RTEMS_SUCCESSFUL
+starting task: bdt0: RTEMS_SUCCESSFUL
+creating task: bdt1: priority: 29: RTEMS_SUCCESSFUL
+starting task: bdt1: RTEMS_SUCCESSFUL
+creating task: bdt2: priority: 28: RTEMS_SUCCESSFUL
+starting task: bdt2: RTEMS_SUCCESSFUL
 test 1: Task 0 get buffer 0 from pool 0
-master: wake task 0: 0a010003: successful completion
-bdt0: rtems_bdbuf_get[0]: successful completion
-bdt0: rtems_bdbuf_release[0]: successful completion
-bdt0: rtems_bdbuf_get[0]: successful completion
-bdt0: rtems_bdbuf_release[0]: successful completion
+master: wake task 0: 0a010003: bdt0: rtems_bdbuf_get[0]: RTEMS_SUCCESSFUL
+bdt0: rtems_bdbuf_release[0]: RTEMS_SUCCESSFUL
+bdt0: rtems_bdbuf_get[0]: RTEMS_SUCCESSFUL
+bdt0: rtems_bdbuf_release[0]: RTEMS_SUCCESSFUL
+RTEMS_SUCCESSFUL
 test 1: passed
 test 2: Task 0 get buffer 0 -> 4 from pool 0, task 2 and 1 block getting
-master: wake task 0: 0a010003: successful completion
-bdt0: rtems_bdbuf_get[0]: successful completion
-bdt0: rtems_bdbuf_get[1]: successful completion
-bdt0: rtems_bdbuf_get[2]: successful completion
-bdt0: rtems_bdbuf_get[3]: successful completion
-bdt0: rtems_bdbuf_get[4]: successful completion
-bdt0: wake master: 0a010001: successful completion
-master: wake task 1: 0a010004: successful completion
-master: wake task 2: 0a010005: successful completion
-master: wake task 0: 0a010003: successful completion
-bdt2: rtems_bdbuf_get[0]: blocking ...
-bdt1: rtems_bdbuf_get[0]: blocking ...
-bdt0: rtems_bdbuf_release[0]: unblocks task 1
-bdt2: rtems_bdbuf_get[0]: successful completion
-bdt2: rtems_bdbuf_release[0]: successful completion
-bdt2: wake master: 0a010001: successful completion
+master: wake task 0: 0a010003: bdt0: rtems_bdbuf_get[0]: RTEMS_SUCCESSFUL
+bdt0: rtems_bdbuf_get[1]: RTEMS_SUCCESSFUL
+bdt0: rtems_bdbuf_get[2]: RTEMS_SUCCESSFUL
+bdt0: rtems_bdbuf_get[3]: RTEMS_SUCCESSFUL
+bdt0: rtems_bdbuf_get[4]: RTEMS_SUCCESSFUL
+bdt0: wake master: 0a010001: RTEMS_SUCCESSFUL
+RTEMS_SUCCESSFUL
+master: wake task 1: 0a010004: bdt1: rtems_bdbuf_get[0]: blocking ...
+RTEMS_SUCCESSFUL
+master: wake task 2: 0a010005: bdt2: rtems_bdbuf_get[0]: blocking ...
+RTEMS_SUCCESSFUL
+master: wake task 0: 0a010003: bdt0: rtems_bdbuf_release[0]: unblocks task 1
+bdt2: rtems_bdbuf_get[0]: RTEMS_SUCCESSFUL
+bdt2: rtems_bdbuf_release[0]: RTEMS_SUCCESSFUL
+bdt2: wake master: 0a010001: RTEMS_SUCCESSFUL
 bdt2: rtems_bdbuf_get[1]: blocking ...
-bdt1: rtems_bdbuf_get[0]: successful completion
-bdt1: rtems_bdbuf_release[0]: successful completion
+bdt1: rtems_bdbuf_get[0]: RTEMS_SUCCESSFUL
+bdt1: rtems_bdbuf_release[0]: RTEMS_SUCCESSFUL
 bdt1: rtems_bdbuf_get[1]: blocking ...
-bdt0: rtems_bdbuf_release[0]: successful completion
-master: wake task 0: 0a010003: successful completion
-bdt0: rtems_bdbuf_release[1]: unblocks task 1
-bdt2: rtems_bdbuf_get[1]: successful completion
-bdt2: rtems_bdbuf_release[1]: successful completion
-bdt2: wake master: 0a010001: successful completion
+bdt0: rtems_bdbuf_release[0]: RTEMS_SUCCESSFUL
+RTEMS_SUCCESSFUL
+master: wake task 0: 0a010003: bdt0: rtems_bdbuf_release[1]: unblocks task 1
+bdt2: rtems_bdbuf_get[1]: RTEMS_SUCCESSFUL
+bdt2: rtems_bdbuf_release[1]: RTEMS_SUCCESSFUL
+bdt2: wake master: 0a010001: RTEMS_SUCCESSFUL
 bdt2: rtems_bdbuf_get[2]: blocking ...
-bdt1: rtems_bdbuf_get[1]: successful completion
-bdt1: rtems_bdbuf_release[1]: successful completion
+bdt1: rtems_bdbuf_get[1]: RTEMS_SUCCESSFUL
+bdt1: rtems_bdbuf_release[1]: RTEMS_SUCCESSFUL
 bdt1: rtems_bdbuf_get[2]: blocking ...
-bdt0: rtems_bdbuf_release[1]: successful 

[PATCH 06/21] libtests/block05: Avoid uninitialized variable

[Sebastian Huber]

Update #3358.
---
 testsuites/libtests/block05/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/testsuites/libtests/block05/init.c 
b/testsuites/libtests/block05/init.c
index 6aafb0e5a6..9bc56af5d5 100644
--- a/testsuites/libtests/block05/init.c
+++ b/testsuites/libtests/block05/init.c
@@ -412,7 +412,7 @@ static void disk_register(
   ASSERT_SC(sc);
 
   fd = open(dev, O_RDWR);
-  rtems_test_assert(rv >= 0);
+  rtems_test_assert(fd >= 0);
 
   rv = rtems_disk_fd_get_disk_device(fd, dd_ptr);
   rtems_test_assert(rv == 0);
-- 
2.13.7

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 13/21] libtests/block14: Use rtems_blkdev_create()

[Sebastian Huber]

Update #3358.
---
 testsuites/libtests/block14/init.c | 44 ++
 1 file changed, 25 insertions(+), 19 deletions(-)

diff --git a/testsuites/libtests/block14/init.c 
b/testsuites/libtests/block14/init.c
index 879582f214..36325f5892 100644
--- a/testsuites/libtests/block14/init.c
+++ b/testsuites/libtests/block14/init.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (c) 2012 embedded brains GmbH.  All rights reserved.
+ * Copyright (c) 2012, 2018 embedded brains GmbH.  All rights reserved.
  *
  *  embedded brains GmbH
- *  Obere Lagerstr. 30
+ *  Dornierstr. 4
  *  82178 Puchheim
  *  Germany
  *  
@@ -18,10 +18,13 @@
 
 #include "tmacros.h"
 
+#include 
+#include 
 #include 
+#include 
 #include 
+#include 
 
-#include 
 #include 
 
 const char rtems_test_name[] = "BLOCK 14";
@@ -30,6 +33,8 @@ const char rtems_test_name[] = "BLOCK 14";
 
 #define BLOCK_COUNT 6
 
+#define DISK_PATH "/disk"
+
 typedef struct {
   rtems_blkdev_bnum block;
   rtems_status_code (*get)(
@@ -109,8 +114,7 @@ static int test_disk_ioctl(rtems_disk_device *dd, uint32_t 
req, void *arg)
 
 rtems_blkdev_request_done(breq, sc);
   } else {
-errno = EINVAL;
-rv = -1;
+rv = rtems_blkdev_ioctl(dd, req, arg);
   }
 
   return rv;
@@ -161,32 +165,32 @@ static void test_actions(rtems_disk_device *dd)
 static void test(void)
 {
   rtems_status_code sc;
-  dev_t dev = 0;
   rtems_disk_device *dd;
+  int fd;
+  int rv;
 
-  sc = rtems_disk_io_initialize();
-  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
-
-  sc = rtems_disk_create_phys(
-dev,
+  sc = rtems_blkdev_create(
+DISK_PATH,
 1,
 BLOCK_COUNT,
 test_disk_ioctl,
-NULL,
 NULL
   );
   rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 
-  dd = rtems_disk_obtain(dev);
-  rtems_test_assert(dd != NULL);
+  fd = open(DISK_PATH, O_RDWR);
+  rtems_test_assert(fd >= 0);
 
-  test_actions(dd);
+  rv = rtems_disk_fd_get_disk_device(fd, );
+  rtems_test_assert(rv == 0);
 
-  sc = rtems_disk_release(dd);
-  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+  rv = close(fd);
+  rtems_test_assert(rv == 0);
 
-  sc = rtems_disk_delete(dev);
-  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+  test_actions(dd);
+
+  rv = unlink(DISK_PATH);
+  rtems_test_assert(rv == 0);
 }
 
 static void Init(rtems_task_argument arg)
@@ -204,6 +208,8 @@ static void Init(rtems_task_argument arg)
 #define CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER
 #define CONFIGURE_APPLICATION_NEEDS_LIBBLOCK
 
+#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 4
+
 #define CONFIGURE_BDBUF_BUFFER_MIN_SIZE 1
 #define CONFIGURE_BDBUF_BUFFER_MAX_SIZE 1
 #define CONFIGURE_BDBUF_CACHE_MEMORY_SIZE BLOCK_COUNT
-- 
2.13.7

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 03/21] flashdisk: Use rtems_blkdev_create()

[Sebastian Huber]

Update #3358.
---
 cpukit/libblock/src/flashdisk.c| 69 +++---
 testsuites/libtests/flashdisk01/init.c |  9 +
 2 files changed, 23 insertions(+), 55 deletions(-)

diff --git a/cpukit/libblock/src/flashdisk.c b/cpukit/libblock/src/flashdisk.c
index 0543f301df..37bcd9d150 100644
--- a/cpukit/libblock/src/flashdisk.c
+++ b/cpukit/libblock/src/flashdisk.c
@@ -41,10 +41,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
-#include 
 #include 
 #include 
 
@@ -206,16 +206,6 @@ typedef struct rtems_flashdisk
 } rtems_flashdisk;
 
 /**
- * The array of flash disks we support.
- */
-static rtems_flashdisk* rtems_flashdisks;
-
-/**
- * The number of flash disks we have.
- */
-static uint32_t rtems_flashdisk_count;
-
-/**
  * The CRC16 factor table. Created during initialisation.
  */
 static uint16_t* rtems_fdisk_crc16_factor;
@@ -2374,19 +2364,17 @@ rtems_fdisk_print_status (rtems_flashdisk* fd)
 static int
 rtems_fdisk_ioctl (rtems_disk_device *dd, uint32_t req, void* argp)
 {
-  dev_t dev = rtems_disk_get_device_identifier (dd);
-  rtems_device_minor_number minor = rtems_filesystem_dev_minor_t (dev);
-  rtems_blkdev_request* r = argp;
+  rtems_flashdisk*  fd = rtems_disk_get_driver_data (dd);
+  rtems_blkdev_request* r = argp;
 
   errno = 0;
 
-  rtems_mutex_lock (_flashdisks[minor].lock);
+  rtems_mutex_lock (>lock);
 
   switch (req)
   {
 case RTEMS_BLKIO_REQUEST:
-  if ((minor >= rtems_flashdisk_count) ||
-  (rtems_flashdisks[minor].device_count == 0))
+  if (fd->device_count == 0)
   {
 errno = ENODEV;
   }
@@ -2395,11 +2383,11 @@ rtems_fdisk_ioctl (rtems_disk_device *dd, uint32_t req, 
void* argp)
 switch (r->req)
 {
   case RTEMS_BLKDEV_REQ_READ:
-errno = rtems_fdisk_read (_flashdisks[minor], r);
+errno = rtems_fdisk_read (fd, r);
 break;
 
   case RTEMS_BLKDEV_REQ_WRITE:
-errno = rtems_fdisk_write (_flashdisks[minor], r);
+errno = rtems_fdisk_write (fd, r);
 break;
 
   default:
@@ -2410,28 +2398,28 @@ rtems_fdisk_ioctl (rtems_disk_device *dd, uint32_t req, 
void* argp)
   break;
 
 case RTEMS_FDISK_IOCTL_ERASE_DISK:
-  errno = rtems_fdisk_erase_disk (_flashdisks[minor]);
+  errno = rtems_fdisk_erase_disk (fd);
   break;
 
 case RTEMS_FDISK_IOCTL_COMPACT:
-  errno = rtems_fdisk_compact (_flashdisks[minor]);
+  errno = rtems_fdisk_compact (fd);
   break;
 
 case RTEMS_FDISK_IOCTL_ERASE_USED:
-  errno = rtems_fdisk_erase_used (_flashdisks[minor]);
+  errno = rtems_fdisk_erase_used (fd);
   break;
 
 case RTEMS_FDISK_IOCTL_MONITORING:
-  errno = rtems_fdisk_monitoring_data (_flashdisks[minor],
+  errno = rtems_fdisk_monitoring_data (fd,
(rtems_fdisk_monitor_data*) argp);
   break;
 
 case RTEMS_FDISK_IOCTL_INFO_LEVEL:
-  rtems_flashdisks[minor].info_level = (uintptr_t) argp;
+  fd->info_level = (uintptr_t) argp;
   break;
 
 case RTEMS_FDISK_IOCTL_PRINT_STATUS:
-  errno = rtems_fdisk_print_status (_flashdisks[minor]);
+  errno = rtems_fdisk_print_status (fd);
   break;
 
 default:
@@ -2439,7 +2427,7 @@ rtems_fdisk_ioctl (rtems_disk_device *dd, uint32_t req, 
void* argp)
   break;
   }
 
-  rtems_mutex_unlock (_flashdisks[minor].lock);
+  rtems_mutex_unlock (>lock);
 
   return errno == 0 ? 0 : -1;
 }
@@ -2462,30 +2450,21 @@ rtems_fdisk_initialize (rtems_device_major_number major,
   rtems_flashdisk*  fd;
   rtems_status_code sc;
 
-  sc = rtems_disk_io_initialize ();
-  if (sc != RTEMS_SUCCESSFUL)
-return sc;
-
   sc = rtems_fdisk_crc16_gen_factors (0x8408);
   if (sc != RTEMS_SUCCESSFUL)
   return sc;
 
-  rtems_flashdisks = calloc (rtems_flashdisk_configuration_size,
- sizeof (rtems_flashdisk));
-
-  if (!rtems_flashdisks)
+  fd = calloc (rtems_flashdisk_configuration_size, sizeof (*fd));
+  if (!fd)
 return RTEMS_NO_MEMORY;
 
-  for (minor = 0; minor < rtems_flashdisk_configuration_size; minor++, c++)
+  for (minor = 0; minor < rtems_flashdisk_configuration_size; minor++, c++, 
fd++)
   {
 char name[] = RTEMS_FLASHDISK_DEVICE_BASE_NAME "a";
-dev_tdev = rtems_filesystem_make_dev_t (major, minor);
 uint32_t device;
 uint32_t blocks = 0;
 int  ret;
 
-fd = _flashdisks[minor];
-
 name [sizeof(RTEMS_FLASHDISK_DEVICE_BASE_NAME)] += minor;
 
 fd->major  = major;
@@ -2520,13 +2499,11 @@ rtems_fdisk_initialize (rtems_device_major_number major,
 
 rtems_mutex_init (>lock, "Flash Disk");
 
-sc = rtems_disk_create_phys(dev, c->block_size,
-blocks - fd->unavail_blocks,
-rtems_fdisk_ioctl, NULL, name);
+sc = rtems_blkdev_create(name, 

[PATCH 18/21] tests: Avoid deprecated rtems_disk_io_initialize()

[Sebastian Huber]

Update #3358.
---
 testsuites/fstests/fsdosfsformat01/init.c | 3 ---
 testsuites/fstests/fsdosfssync01/init.c   | 3 ---
 testsuites/fstests/fsdosfswrite01/init.c  | 4 
 testsuites/libtests/block11/init.c| 9 -
 testsuites/libtests/block16/init.c| 3 ---
 testsuites/libtests/sparsedisk01/init.c   | 4 
 6 files changed, 26 deletions(-)

diff --git a/testsuites/fstests/fsdosfsformat01/init.c 
b/testsuites/fstests/fsdosfsformat01/init.c
index fb5896dca4..a8477cb61f 100644
--- a/testsuites/fstests/fsdosfsformat01/init.c
+++ b/testsuites/fstests/fsdosfsformat01/init.c
@@ -176,9 +176,6 @@ static void test( void )
 
   memset( , 0, sizeof( rqdata ) );
 
-  sc = rtems_disk_io_initialize();
-  rtems_test_assert( sc == RTEMS_SUCCESSFUL );
-
   rv = mkdir( mount_dir, S_IRWXU | S_IRWXG | S_IRWXO );
   rtems_test_assert( 0 == rv );
 
diff --git a/testsuites/fstests/fsdosfssync01/init.c 
b/testsuites/fstests/fsdosfssync01/init.c
index 5aee87622c..e878e59075 100644
--- a/testsuites/fstests/fsdosfssync01/init.c
+++ b/testsuites/fstests/fsdosfssync01/init.c
@@ -100,9 +100,6 @@ static void test(const char *rda, const char *mnt, const 
char *file)
   int disk_fd;
   int rv;
 
-  sc = rtems_disk_io_initialize();
-  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
-
   disk_fd = open(rda, O_RDWR);
   rtems_test_assert(disk_fd >= 0);
 
diff --git a/testsuites/fstests/fsdosfswrite01/init.c 
b/testsuites/fstests/fsdosfswrite01/init.c
index 9cc7fe..5048bdb224 100644
--- a/testsuites/fstests/fsdosfswrite01/init.c
+++ b/testsuites/fstests/fsdosfswrite01/init.c
@@ -251,10 +251,6 @@ static void test( void )
   rtems_status_code sc;
   int   rv;
 
-
-  sc = rtems_disk_io_initialize();
-  rtems_test_assert( sc == RTEMS_SUCCESSFUL );
-
   rv = mkdir( mount_dir, S_IRWXU | S_IRWXG | S_IRWXO );
   rtems_test_assert( 0 == rv );
 
diff --git a/testsuites/libtests/block11/init.c 
b/testsuites/libtests/block11/init.c
index f607bf515e..82e24d6548 100644
--- a/testsuites/libtests/block11/init.c
+++ b/testsuites/libtests/block11/init.c
@@ -401,22 +401,13 @@ static void test_blkdev_imfs_errors(void)
 
 static rtems_task Init(rtems_task_argument argument)
 {
-  rtems_status_code sc;
-
   TEST_BEGIN();
 
-  sc = rtems_disk_io_initialize();
-  ASSERT_SC(sc);
-
   test_blkdev_imfs_read_and_write();
   test_blkdev_imfs_parameters();
   test_blkdev_imfs_errors();
 
-  sc = rtems_disk_io_done();
-  ASSERT_SC(sc);
-
   TEST_END();
-
   exit(0);
 }
 
diff --git a/testsuites/libtests/block16/init.c 
b/testsuites/libtests/block16/init.c
index 401a888925..64ccded9dc 100644
--- a/testsuites/libtests/block16/init.c
+++ b/testsuites/libtests/block16/init.c
@@ -48,9 +48,6 @@ static void test(void)
   rtems_bdbuf_buffer *large_bd;
   rtems_blkdev_bnum i;
 
-  sc = rtems_disk_io_initialize();
-  ASSERT_SC(sc);
-
   for (i = 0; i < media_block_count; ++i) {
 buf [i] = i;
   }
diff --git a/testsuites/libtests/sparsedisk01/init.c 
b/testsuites/libtests/sparsedisk01/init.c
index dfb87ecdd5..e0d25fa444 100644
--- a/testsuites/libtests/sparsedisk01/init.c
+++ b/testsuites/libtests/sparsedisk01/init.c
@@ -358,10 +358,6 @@ void test( void )
   int   file_descriptor;
   uint8_t   fill_pattern = 0;
 
-
-  sc = rtems_disk_io_initialize();
-  rtems_test_assert( sc == RTEMS_SUCCESSFUL );
-
   block_size   = 512;
   block_number = 4 * 2 * 1024;
   blocks_allocated = 8;
-- 
2.13.7

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 17/21] bsp/gen5200: Avoid deprecated routine

[Sebastian Huber]

Update #3358.
---
 bsps/powerpc/gen5200/ata/ata-instance.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/bsps/powerpc/gen5200/ata/ata-instance.c 
b/bsps/powerpc/gen5200/ata/ata-instance.c
index b2b26341f6..df753a5e58 100644
--- a/bsps/powerpc/gen5200/ata/ata-instance.c
+++ b/bsps/powerpc/gen5200/ata/ata-instance.c
@@ -17,6 +17,8 @@
 
 #include 
 
+#include 
+
 #include 
 
 static ata_driver_dma_pio_single ata_driver_instance;
@@ -27,7 +29,7 @@ rtems_status_code rtems_ata_initialize(
   void *arg
 )
 {
-  rtems_status_code sc = rtems_disk_io_initialize();
+  rtems_status_code sc = rtems_bdbuf_init();
 
   if (sc == RTEMS_SUCCESSFUL) {
 bestcomm_glue_init();
-- 
2.13.7

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 05/21] bsp/smdk2410: Use rtems_blkdev_create()

[Sebastian Huber]

Update #3358.
---
 bsps/arm/smdk2410/smc/smc.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/bsps/arm/smdk2410/smc/smc.c b/bsps/arm/smdk2410/smc/smc.c
index 8291008336..459407f275 100644
--- a/bsps/arm/smdk2410/smc/smc.c
+++ b/bsps/arm/smdk2410/smc/smc.c
@@ -14,8 +14,7 @@
 #include 
 #include 
 
-#include "rtems/blkdev.h"
-#include "rtems/diskdevs.h"
+#include 
 #include "smc.h"
 #include 
 #include 
@@ -392,19 +391,12 @@ smc_initialize(
 void *arg)
 {
 rtems_status_code rc;
-dev_t dev;
 uint32_t block_num;
 
-rc = rtems_disk_io_initialize();
-if (rc != RTEMS_SUCCESSFUL)
-return rc;
-
 smc_init();
 block_num = smc_info.blocks << 5;
 
-dev = rtems_filesystem_make_dev_t(major, 0);
-rc = rtems_disk_create_phys(dev, 512, block_num,
-smc_ioctl, NULL, SMC_DEVICE_NAME);
+rc = rtems_blkdev_create(SMC_DEVICE_NAME, 512, block_num, smc_ioctl);
 
-return RTEMS_SUCCESSFUL;
+return rc;
 }
-- 
2.13.7

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 09/21] libtests/block09: Use rtems_blkdev_create()

[Sebastian Huber]

Update #3358.
---
 testsuites/libtests/block09/init.c | 65 +++---
 1 file changed, 25 insertions(+), 40 deletions(-)

diff --git a/testsuites/libtests/block09/init.c 
b/testsuites/libtests/block09/init.c
index b25c4e4113..3e8b8cd83e 100644
--- a/testsuites/libtests/block09/init.c
+++ b/testsuites/libtests/block09/init.c
@@ -7,10 +7,10 @@
  */
 
 /*
- * Copyright (c) 2009-2012 embedded brains GmbH.  All rights reserved.
+ * Copyright (c) 2009, 2018 embedded brains GmbH.  All rights reserved.
  *
  *  embedded brains GmbH
- *  Obere Lagerstr. 30
+ *  Dornierstr. 4
  *  82178 Puchheim
  *  Germany
  *  
@@ -26,22 +26,21 @@
 
 #include "tmacros.h"
 
+#include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #include 
 #include 
-#include 
 #include 
 
 #include 
 
 const char rtems_test_name[] = "BLOCK 9";
 
-/* forward declarations to avoid warnings */
-static rtems_task Init(rtems_task_argument argument);
-
 #define ASSERT_SC(sc) assert((sc) == RTEMS_SUCCESSFUL)
 
 #define BLOCK_SIZE sizeof(char)
@@ -53,12 +52,9 @@ static rtems_task Init(rtems_task_argument argument);
 #define BLOCK_READ_SUCCESSFUL 2
 #define BLOCK_WRITE_IO_ERROR 3
 
-static char disk_data [BLOCK_COUNT];
+#define DISK_PATH "/disk"
 
-static const rtems_driver_address_table disk_ops = {
-  .initialization_entry = NULL,
-  RTEMS_GENERIC_BLOCK_DEVICE_DRIVER_ENTRIES
-};
+static char disk_data [BLOCK_COUNT];
 
 static int disk_ioctl(rtems_disk_device *dd, uint32_t req, void *arg)
 {
@@ -123,34 +119,33 @@ static int disk_ioctl(rtems_disk_device *dd, uint32_t 
req, void *arg)
   }
 }
 
-static rtems_status_code disk_register(
+static void disk_register(
   uint32_t block_size,
   rtems_blkdev_bnum block_count,
-  dev_t *dev_ptr
+  rtems_disk_device **dd
 )
 {
-  rtems_status_code sc = RTEMS_SUCCESSFUL;
-  rtems_device_major_number major = 0;
-  dev_t dev = 0;
+  rtems_status_code sc;
+  int fd;
+  int rv;
 
-  sc = rtems_io_register_driver(0, _ops, );
-  ASSERT_SC(sc);
-
-  dev = rtems_filesystem_make_dev_t(major, 0);
-
-  sc = rtems_disk_create_phys(
-dev,
+  sc = rtems_blkdev_create(
+DISK_PATH,
 block_size,
 block_count,
 disk_ioctl,
-NULL,
 NULL
   );
   ASSERT_SC(sc);
 
-  *dev_ptr = dev;
+  fd = open(DISK_PATH, O_RDWR);
+  rtems_test_assert(fd >= 0);
+
+  rv = rtems_disk_fd_get_disk_device(fd, dd);
+  rtems_test_assert(rv == 0);
 
-  return RTEMS_SUCCESSFUL;
+  rv = close(fd);
+  rtems_test_assert(rv == 0);
 }
 
 static void check_read(
@@ -175,19 +170,11 @@ static rtems_task Init(rtems_task_argument argument)
 {
   rtems_status_code sc = RTEMS_SUCCESSFUL;
   rtems_bdbuf_buffer *bd = NULL;
-  dev_t dev = 0;
   rtems_disk_device *dd = NULL;
 
   TEST_BEGIN();
 
-  sc = rtems_disk_io_initialize();
-  ASSERT_SC(sc);
-
-  sc = disk_register(BLOCK_SIZE, BLOCK_COUNT, );
-  ASSERT_SC(sc);
-
-  dd = rtems_disk_obtain(dev);
-  assert(dd != NULL);
+  disk_register(BLOCK_SIZE, BLOCK_COUNT, );
 
   check_read(dd, BLOCK_READ_IO_ERROR, RTEMS_IO_ERROR);
   check_read(dd, BLOCK_READ_UNSATISFIED, RTEMS_UNSATISFIED);
@@ -217,15 +204,12 @@ static rtems_task Init(rtems_task_argument argument)
   sc = rtems_bdbuf_read(dd, BLOCK_READ_SUCCESSFUL, );
   ASSERT_SC(sc);
 
-  sc = rtems_disk_delete(dev);
+  sc = unlink(DISK_PATH);
   ASSERT_SC(sc);
 
   sc = rtems_bdbuf_sync(bd);
   ASSERT_SC(sc);
 
-  sc = rtems_disk_release(dd);
-  ASSERT_SC(sc);
-
   TEST_END();
 
   exit(0);
@@ -237,8 +221,9 @@ static rtems_task Init(rtems_task_argument argument)
 #define CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER
 #define CONFIGURE_APPLICATION_NEEDS_LIBBLOCK
 
+#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 4
+
 #define CONFIGURE_MAXIMUM_TASKS 1
-#define CONFIGURE_MAXIMUM_DRIVERS 4
 
 #define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
 
-- 
2.13.7

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 15/21] libblock: Use rtems_blkdev_create_partition()

[Sebastian Huber]

Update #3358.
---
 cpukit/include/rtems/ide_part_table.h |  2 --
 cpukit/libblock/src/ide_part_table.c  | 16 ++--
 2 files changed, 2 insertions(+), 16 deletions(-)

diff --git a/cpukit/include/rtems/ide_part_table.h 
b/cpukit/include/rtems/ide_part_table.h
index 8b683b3ff5..9fd991ec5f 100644
--- a/cpukit/include/rtems/ide_part_table.h
+++ b/cpukit/include/rtems/ide_part_table.h
@@ -126,8 +126,6 @@ typedef struct rtems_part_desc_s {
 
 
 typedef struct rtems_disk_desc_s {
-dev_tdev; /* device number */
-
 /* device name in /dev filesystem */
 char dev_name[RTEMS_IDE_PARTITION_DEV_NAME_LENGTH_MAX];
 
diff --git a/cpukit/libblock/src/ide_part_table.c 
b/cpukit/libblock/src/ide_part_table.c
index 58a8d87284..5d40130ea4 100644
--- a/cpukit/libblock/src/ide_part_table.c
+++ b/cpukit/libblock/src/ide_part_table.c
@@ -487,7 +487,6 @@ partition_table_get(const char *dev_name, rtems_disk_desc_t 
*disk_desc)
 }
 
 strncpy (disk_desc->dev_name, dev_name, 15);
-disk_desc->dev = dev_stat.st_rdev;
 disk_desc->sector_size = (dev_stat.st_blksize) ? dev_stat.st_blksize :
   RTEMS_IDE_SECTOR_SIZE;
 
@@ -550,10 +549,7 @@ rtems_status_code
 rtems_ide_part_table_initialize(const char *dev_name)
 {
 int part_num;
-dev_t   dev;
 rtems_disk_desc_t  *disk_desc;
-rtems_device_major_number   major;
-rtems_device_minor_number   minor;
 rtems_status_code   rc;
 rtems_part_desc_t  *part_desc;
 
@@ -574,18 +570,10 @@ rtems_ide_part_table_initialize(const char *dev_name)
 return rc;
 }
 
-/* To avoid device numbers conflicts we have to use for logic disk the same
- * device major number as ATA device has, and minor number that equals to
- * sum of logic disk partition number and the minor number of physical disk
- */
-
-rtems_filesystem_split_dev_t (disk_desc->dev, major, minor);
-
 /* create logical disks on the physical one */
 for (part_num = 0; part_num < disk_desc->last_log_id; part_num++)
 {
 sprintf(name, "%s%d", dev_name, part_num + 1);
-dev = rtems_filesystem_make_dev_t(major, ++minor);
 
 part_desc = disk_desc->partitions[part_num];
 if (part_desc == NULL)
@@ -593,8 +581,8 @@ rtems_ide_part_table_initialize(const char *dev_name)
 continue;
 }
 
-rc = rtems_disk_create_log(dev, disk_desc->dev, part_desc->start,
-   part_desc->size, name);
+rc = rtems_blkdev_create_partition(name, dev_name, part_desc->start,
+   part_desc->size);
 if (rc != RTEMS_SUCCESSFUL)
 {
 fprintf(stdout,"Cannot create device %s, error code %d\n", name, 
rc);
-- 
2.13.7

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 01/21] ramdisk: Use rtems_blkdev_create()

[Sebastian Huber]

Update #3358.
---
 cpukit/include/rtems/ramdisk.h |  9 +--
 cpukit/libblock/src/ramdisk-config.c   | 11 +---
 cpukit/libblock/src/ramdisk-register.c | 30 ++
 testsuites/fstests/fsdosfsname01/init.c| 35 +--
 testsuites/fstests/mdosfs_support/fs_support.c |  1 -
 testsuites/fstests/mrfs_support/fs_support.c   |  1 -
 testsuites/fstests/support/ramdisk_support.c   | 27 ++---
 testsuites/libtests/block01/init.c | 12 ++--
 testsuites/libtests/block02/init.c | 57 +++---
 testsuites/libtests/block03/init.c | 49 ++-
 testsuites/libtests/block04/init.c | 49 ++-
 testsuites/libtests/block07/init.c | 53 +---
 testsuites/samples/fileio/init.c   | 83 --
 13 files changed, 181 insertions(+), 236 deletions(-)

diff --git a/cpukit/include/rtems/ramdisk.h b/cpukit/include/rtems/ramdisk.h
index 727efddbe8..dcc60483dd 100644
--- a/cpukit/include/rtems/ramdisk.h
+++ b/cpukit/include/rtems/ramdisk.h
@@ -84,8 +84,8 @@ rtems_device_driver ramdisk_initialize(
  */
 #define RAMDISK_DRIVER_TABLE_ENTRY \
   { \
-.initialization_entry = ramdisk_initialize, \
-RTEMS_GENERIC_BLOCK_DEVICE_DRIVER_ENTRIES \
+ramdisk_initialize, \
+NULL, NULL, NULL, NULL, NULL \
   }
 
 #define RAMDISK_DEVICE_BASE_NAME "/dev/rd"
@@ -137,8 +137,6 @@ typedef struct ramdisk {
   bool free_at_delete_request;
 } ramdisk;
 
-extern const rtems_driver_address_table ramdisk_ops;
-
 int ramdisk_ioctl(rtems_disk_device *dd, uint32_t req, void *argp);
 
 /**
@@ -212,8 +210,7 @@ rtems_status_code ramdisk_register(
   uint32_t media_block_size,
   rtems_blkdev_bnum media_block_count,
   bool trace,
-  const char *disk,
-  dev_t *dev
+  const char *disk
 );
 
 /** @} */
diff --git a/cpukit/libblock/src/ramdisk-config.c 
b/cpukit/libblock/src/ramdisk-config.c
index 7bd137a394..8e1b277674 100644
--- a/cpukit/libblock/src/ramdisk-config.c
+++ b/cpukit/libblock/src/ramdisk-config.c
@@ -23,7 +23,7 @@
 
 rtems_device_driver
 ramdisk_initialize(
-rtems_device_major_number major,
+rtems_device_major_number major RTEMS_UNUSED,
 rtems_device_minor_number minor RTEMS_UNUSED,
 void *arg RTEMS_UNUSED)
 {
@@ -32,10 +32,6 @@ ramdisk_initialize(
 struct ramdisk *r;
 rtems_status_code rc;
 
-rc = rtems_disk_io_initialize();
-if (rc != RTEMS_SUCCESSFUL)
-return rc;
-
 /*
  * Coverity Id 27 notes that this calloc() is a resource leak.
  *
@@ -48,7 +44,6 @@ ramdisk_initialize(
 r->trace = false;
 for (i = 0; i < rtems_ramdisk_configuration_size; i++, c++, r++)
 {
-dev_t dev = rtems_filesystem_make_dev_t(major, i);
 char name [] = RAMDISK_DEVICE_BASE_NAME "a";
 name [sizeof(RAMDISK_DEVICE_BASE_NAME) - 1] += i;
 r->block_size = c->block_size;
@@ -73,8 +68,8 @@ ramdisk_initialize(
 r->initialized = true;
 r->area = c->location;
 }
-rc = rtems_disk_create_phys(dev, c->block_size, c->block_num,
-ramdisk_ioctl, r, name);
+rc = rtems_blkdev_create(name, c->block_size, c->block_num,
+ ramdisk_ioctl, r);
 if (rc != RTEMS_SUCCESSFUL)
 {
 if (r->malloced)
diff --git a/cpukit/libblock/src/ramdisk-register.c 
b/cpukit/libblock/src/ramdisk-register.c
index ec133d0c03..6b2dc2c36d 100644
--- a/cpukit/libblock/src/ramdisk-register.c
+++ b/cpukit/libblock/src/ramdisk-register.c
@@ -24,57 +24,35 @@
   #include "config.h"
 #endif
 
-#include 
 #include 
 
-const rtems_driver_address_table ramdisk_ops = {
-  .initialization_entry = NULL,
-  RTEMS_GENERIC_BLOCK_DEVICE_DRIVER_ENTRIES
-};
-
 rtems_status_code ramdisk_register(
   uint32_t media_block_size,
   rtems_blkdev_bnum media_block_count,
   bool trace,
-  const char *disk,
-  dev_t *dev_ptr
+  const char *disk
 )
 {
   rtems_status_code sc = RTEMS_SUCCESSFUL;
-  rtems_device_major_number major = 0;
   ramdisk *rd = NULL;
-  dev_t dev = 0;
-
-  sc = rtems_io_register_driver(0, _ops, );
-  if (sc != RTEMS_SUCCESSFUL) {
-return RTEMS_UNSATISFIED;
-  }
 
   rd = ramdisk_allocate(NULL, media_block_size, media_block_count, trace);
   if (rd == NULL) {
-rtems_io_unregister_driver(major);
-
 return RTEMS_UNSATISFIED;
   }
 
-  dev = rtems_filesystem_make_dev_t(major, 0);
-
-  sc = rtems_disk_create_phys(
-dev,
+  sc = rtems_blkdev_create(
+disk,
 media_block_size,
 media_block_count,
 ramdisk_ioctl,
-rd,
-disk
+rd
   );
   if (sc != RTEMS_SUCCESSFUL) {
 ramdisk_free(rd);
-rtems_io_unregister_driver(major);
 
 return RTEMS_UNSATISFIED;
   }
 
-  *dev_ptr = dev;
-
   return RTEMS_SUCCESSFUL;
 }
diff --git a/testsuites/fstests/fsdosfsname01/init.c 
b/testsuites/fstests/fsdosfsname01/init.c
index ce6850cfa7..90db282955 100644
--- 

[PATCH 08/21] libtests/block08: Use rtems_blkdev_create()

[Sebastian Huber]

Update #3358.
---
 testsuites/libtests/block08/bdbuf_tests.c | 59 +--
 testsuites/libtests/block08/bdbuf_tests.h |  7 +---
 testsuites/libtests/block08/system.h  |  9 ++---
 testsuites/libtests/block08/test_disk.c   | 29 +--
 4 files changed, 27 insertions(+), 77 deletions(-)

diff --git a/testsuites/libtests/block08/bdbuf_tests.c 
b/testsuites/libtests/block08/bdbuf_tests.c
index 66e69d4fbd..8cf0111dbc 100644
--- a/testsuites/libtests/block08/bdbuf_tests.c
+++ b/testsuites/libtests/block08/bdbuf_tests.c
@@ -13,17 +13,20 @@
 #include "config.h"
 #endif
 
+#include 
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include "bdbuf_tests.h"
 
+#include 
 
 struct bdbuf_test_descr {
 void (* main)(void);
@@ -105,17 +108,10 @@ bdbuf_test_start_aux_task(rtems_name name,
 void
 run_bdbuf_tests()
 {
-rtems_disk_device  *disk;
-rtems_status_code   sc;
-dev_t   dev = -1;
-dev_t   test_dev;
-unsigned inti;
-
-rtems_device_major_number  major;
-rtems_driver_address_table testdisk = {
-test_disk_initialize,
-RTEMS_GENERIC_BLOCK_DEVICE_DRIVER_ENTRIES
-};
+rtems_status_code sc;
+unsigned int  i;
+int   fd;
+int   rv;
 
 /* Create a message queue to get events from disk driver. */
 sc = rtems_message_queue_create(TEST_TASK_RX_MQUEUE_NAME,
@@ -130,40 +126,17 @@ run_bdbuf_tests()
 return;
 }
 
-/* Register a disk device that is used in tests */
-sc = rtems_io_register_driver(0, , );
-if (sc != RTEMS_SUCCESSFUL)
-{
-printf("Failed to register TEST DEVICE: %d\n", sc);
-return;
-}
+sc = test_disk_initialize();
+rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 
-test_dev = -1;
-while ((disk = rtems_disk_next(dev)) != NULL)
-{
-printf(
-  "DEV: %s [%" PRIdrtems_blkdev_bnum "]\n",
- disk->name,
-  disk->size
-);
-dev = disk->dev;
-if (strcmp(disk->name, TEST_DISK_NAME) == 0)
-test_dev = dev;
-rtems_disk_release(disk);
-}
+fd = open(TEST_DISK_NAME, O_RDWR);
+rtems_test_assert(fd >= 0);
 
-if (test_dev == (dev_t)-1)
-{
-printf("Failed to find %s disk\n", TEST_DISK_NAME);
-return;
-}
+rv = rtems_disk_fd_get_disk_device(fd, _dd);
+rtems_test_assert(rv == 0);
 
-test_dd = rtems_disk_obtain(test_dev);
-if (test_dd == NULL)
-{
-printf("Failed to obtain %s disk\n", TEST_DISK_NAME);
-return;
-}
+rv = close(fd);
+rtems_test_assert(rv == 0);
 
 /*
  * On initialization test disk device driver registers
diff --git a/testsuites/libtests/block08/bdbuf_tests.h 
b/testsuites/libtests/block08/bdbuf_tests.h
index 72502b3e38..8924eb1f14 100644
--- a/testsuites/libtests/block08/bdbuf_tests.h
+++ b/testsuites/libtests/block08/bdbuf_tests.h
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #ifdef __cplusplus
@@ -46,11 +45,7 @@ extern void bdbuf_test4_1_main(void);
 extern void bdbuf_test4_2_main(void);
 extern void bdbuf_test4_3_main(void);
 
-extern rtems_device_driver
-test_disk_initialize(
-rtems_device_major_number major,
-rtems_device_minor_number minor,
-void *arg);
+extern rtems_status_code test_disk_initialize(void);
 
 #define ARRAY_NUM(a_) (sizeof(a_) / sizeof(a_[0]))
 
diff --git a/testsuites/libtests/block08/system.h 
b/testsuites/libtests/block08/system.h
index 8ceb17e929..bb4a9a0bb1 100644
--- a/testsuites/libtests/block08/system.h
+++ b/testsuites/libtests/block08/system.h
@@ -24,6 +24,8 @@ rtems_task Init(
 #define CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER
 #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
 
+#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 4
+
 #define CONFIGURE_MAXIMUM_TASKS   28
 #define CONFIGURE_MAXIMUM_TIMERS  10
 #define CONFIGURE_MAXIMUM_SEMAPHORES  20
@@ -40,13 +42,6 @@ rtems_task Init(
 #define CONFIGURE_BDBUF_BUFFER_MIN_SIZE (512)
 #define CONFIGURE_BDBUF_BUFFER_MAX_SIZE (512)
 
-/* 
- * Define it here in order to be able to register
- * test driver after RTEMS initialization phase
- * (on test start-up).
- */
-#define CONFIGURE_MAXIMUM_DRIVERS 5
-
 #define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
 
 #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
diff --git a/testsuites/libtests/block08/test_disk.c 
b/testsuites/libtests/block08/test_disk.c
index aa33803b23..5cc15d280a 100644
--- a/testsuites/libtests/block08/test_disk.c
+++ b/testsuites/libtests/block08/test_disk.c
@@ -21,8 +21,7 @@
 #include 
 #include 
 
-#include "rtems/blkdev.h"
-#include "rtems/diskdevs.h"
+#include 
 
 #include "bdbuf_tests.h"
 
@@ -58,9 +57,7 @@ test_disk_ioctl(rtems_disk_device *dd, uint32_t req, void 
*argp)
 }
 
 default:
-printf("%s() 

[PATCH 11/21] libtests/block12: Use rtems_blkdev_create()

[Sebastian Huber]

Update #3358.
---
 testsuites/libtests/block12/init.c | 43 ++
 1 file changed, 25 insertions(+), 18 deletions(-)

diff --git a/testsuites/libtests/block12/init.c 
b/testsuites/libtests/block12/init.c
index 036a4e92e6..ddc27958aa 100644
--- a/testsuites/libtests/block12/init.c
+++ b/testsuites/libtests/block12/init.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (c) 2012 embedded brains GmbH.  All rights reserved.
+ * Copyright (c) 2012, 2018 embedded brains GmbH.  All rights reserved.
  *
  *  embedded brains GmbH
- *  Obere Lagerstr. 30
+ *  Dornierstr. 4
  *  82178 Puchheim
  *  Germany
  *  
@@ -18,8 +18,12 @@
 
 #include "tmacros.h"
 
+#include 
+#include 
 #include 
+#include 
 #include 
+#include 
 
 #include 
 #include 
@@ -28,6 +32,8 @@ const char rtems_test_name[] = "BLOCK 12";
 
 #define BLOCK_COUNT 15
 
+#define DISK_PATH "/disk"
+
 static int block_access_counts [BLOCK_COUNT];
 
 static int expected_block_access_counts [BLOCK_COUNT] = {
@@ -59,8 +65,7 @@ static int test_disk_ioctl(rtems_disk_device *dd, uint32_t 
req, void *arg)
 
 rtems_blkdev_request_done(breq, RTEMS_SUCCESSFUL);
   } else {
-errno = EINVAL;
-rv = -1;
+rv = rtems_blkdev_ioctl(dd, req, arg);
   }
 
   return rv;
@@ -85,24 +90,27 @@ static void do_read_sequence(rtems_disk_device *dd)
 static void test(void)
 {
   rtems_status_code sc;
-  dev_t dev = 0;
+  int fd;
+  int rv;
   rtems_disk_device *dd;
 
-  sc = rtems_disk_io_initialize();
-  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
-
-  sc = rtems_disk_create_phys(
-dev,
+  sc = rtems_blkdev_create(
+DISK_PATH,
 1,
 BLOCK_COUNT,
 test_disk_ioctl,
-NULL,
 NULL
   );
   rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 
-  dd = rtems_disk_obtain(dev);
-  rtems_test_assert(dd != NULL);
+  fd = open(DISK_PATH, O_RDWR);
+  rtems_test_assert(fd >= 0);
+
+  rv = rtems_disk_fd_get_disk_device(fd, );
+  rtems_test_assert(rv == 0);
+
+  rv = close(fd);
+  rtems_test_assert(rv == 0);
 
   do_read_sequence(dd);
   rtems_bdbuf_purge_dev(dd);
@@ -116,11 +124,8 @@ static void test(void)
 ) == 0
   );
 
-  sc = rtems_disk_release(dd);
-  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
-
-  sc = rtems_disk_delete(dev);
-  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+  rv = unlink(DISK_PATH);
+  rtems_test_assert(rv == 0);
 }
 
 static void Init(rtems_task_argument arg)
@@ -138,6 +143,8 @@ static void Init(rtems_task_argument arg)
 #define CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER
 #define CONFIGURE_APPLICATION_NEEDS_LIBBLOCK
 
+#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 4
+
 #define CONFIGURE_BDBUF_BUFFER_MIN_SIZE 1
 #define CONFIGURE_BDBUF_BUFFER_MAX_SIZE 1
 #define CONFIGURE_BDBUF_CACHE_MEMORY_SIZE BLOCK_COUNT
-- 
2.13.7

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 02/21] nvdisk: Use rtems_blkdev_create()

[Sebastian Huber]

Update #3358.
---
 cpukit/libblock/src/nvdisk.c | 70 +++-
 testsuites/samples/fileio/init.c | 61 ++
 2 files changed, 22 insertions(+), 109 deletions(-)

diff --git a/cpukit/libblock/src/nvdisk.c b/cpukit/libblock/src/nvdisk.c
index bb1fc5dbe9..693c0b13a0 100644
--- a/cpukit/libblock/src/nvdisk.c
+++ b/cpukit/libblock/src/nvdisk.c
@@ -26,7 +26,6 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 
@@ -93,10 +92,8 @@ typedef struct rtems_nvdisk_device_ctl
  * The NV disk control structure for a single disk. There is one
  * for each minor disk in the system.
  */
-typedef struct rtems_mvdisk
+typedef struct
 {
-  rtems_device_major_number major;/**< The driver's major number. */
-  rtems_device_minor_number minor;/**< The driver's minor number. */
   uint32_t  flags;/**< configuration flags. */
   uint32_t  block_size;   /**< The block size for this disk. */
   uint32_t  block_count;  /**< The number of available blocks. 
*/
@@ -108,16 +105,6 @@ typedef struct rtems_mvdisk
 } rtems_nvdisk;
 
 /**
- * The array of NV disks we support.
- */
-static rtems_nvdisk* rtems_nvdisks;
-
-/**
- * The number of NV disks we have.
- */
-static uint32_t rtems_nvdisk_count;
-
-/**
  * The CRC16 factor table. Created during initialisation.
  */
 static uint16_t* rtems_nvdisk_crc16_factor;
@@ -688,17 +675,10 @@ rtems_nvdisk_erase_disk (rtems_nvdisk* nvd)
 static int
 rtems_nvdisk_ioctl (rtems_disk_device *dd, uint32_t req, void* argp)
 {
-  dev_t dev = rtems_disk_get_device_identifier (dd);
-  rtems_device_minor_number minor = rtems_filesystem_dev_minor_t (dev);
-  rtems_blkdev_request* r = argp;
-
-  if (minor >= rtems_nvdisk_count)
-  {
-errno = ENODEV;
-return -1;
-  }
+  rtems_nvdisk* nvd = rtems_disk_get_driver_data (dd);
+  rtems_blkdev_request* r = argp;
 
-  if (rtems_nvdisks[minor].device_count == 0)
+  if (nvd->device_count == 0)
   {
 errno = ENODEV;
 return -1;
@@ -706,7 +686,7 @@ rtems_nvdisk_ioctl (rtems_disk_device *dd, uint32_t req, 
void* argp)
 
   errno = 0;
 
-  rtems_mutex_lock (_nvdisks[minor].lock);
+  rtems_mutex_lock (>lock);
 
   switch (req)
   {
@@ -714,11 +694,11 @@ rtems_nvdisk_ioctl (rtems_disk_device *dd, uint32_t req, 
void* argp)
   switch (r->req)
   {
 case RTEMS_BLKDEV_REQ_READ:
-  errno = rtems_nvdisk_read (_nvdisks[minor], r);
+  errno = rtems_nvdisk_read (nvd, r);
   break;
 
 case RTEMS_BLKDEV_REQ_WRITE:
-  errno = rtems_nvdisk_write (_nvdisks[minor], r);
+  errno = rtems_nvdisk_write (nvd, r);
   break;
 
 default:
@@ -728,11 +708,11 @@ rtems_nvdisk_ioctl (rtems_disk_device *dd, uint32_t req, 
void* argp)
   break;
 
 case RTEMS_NVDISK_IOCTL_ERASE_DISK:
-  errno = rtems_nvdisk_erase_disk (_nvdisks[minor]);
+  errno = rtems_nvdisk_erase_disk (nvd);
   break;
 
 case RTEMS_NVDISK_IOCTL_INFO_LEVEL:
-  rtems_nvdisks[minor].info_level = (uintptr_t) argp;
+  nvd->info_level = (uintptr_t) argp;
   break;
 
 default:
@@ -740,7 +720,7 @@ rtems_nvdisk_ioctl (rtems_disk_device *dd, uint32_t req, 
void* argp)
   break;
   }
 
-  rtems_mutex_unlock (_nvdisks[minor].lock);
+  rtems_mutex_unlock (>lock);
 
   return errno == 0 ? 0 : -1;
 }
@@ -755,41 +735,31 @@ rtems_nvdisk_ioctl (rtems_disk_device *dd, uint32_t req, 
void* argp)
  * @param arg Initialization argument, not applicable.
  */
 rtems_device_driver
-rtems_nvdisk_initialize (rtems_device_major_number major,
-rtems_device_minor_number minor,
+rtems_nvdisk_initialize (rtems_device_major_number major RTEMS_UNUSED,
+rtems_device_minor_number minor RTEMS_UNUSED,
 void* arg RTEMS_UNUSED)
 {
   const rtems_nvdisk_config* c = rtems_nvdisk_configuration;
   rtems_nvdisk*  nvd;
   rtems_status_code  sc;
-
-  sc = rtems_disk_io_initialize ();
-  if (sc != RTEMS_SUCCESSFUL)
-return sc;
+  uint32_t   i;
 
   sc = rtems_nvdisk_crc16_gen_factors (0x8408);
   if (sc != RTEMS_SUCCESSFUL)
   return sc;
 
-  rtems_nvdisks = calloc (rtems_nvdisk_configuration_size,
-  sizeof (rtems_nvdisk));
-
-  if (!rtems_nvdisks)
+  nvd = calloc (rtems_nvdisk_configuration_size, sizeof (*nvd));
+  if (!nvd)
 return RTEMS_NO_MEMORY;
 
-  for (minor = 0; minor < rtems_nvdisk_configuration_size; minor++, c++)
+  for (i = 0; i < rtems_nvdisk_configuration_size; i++, c++, nvd++)
   {
 char name[] = RTEMS_NVDISK_DEVICE_BASE_NAME "a";
-dev_tdev = rtems_filesystem_make_dev_t (major, minor);
 uint32_t device;
 uint32_t blocks = 0;
 
-nvd = _nvdisks[minor];
+name [sizeof(RTEMS_NVDISK_DEVICE_BASE_NAME)] += i;
 
-name [sizeof(RTEMS_NVDISK_DEVICE_BASE_NAME)] += minor;

Re: Inlined code

[Chris Johns]

On 06/08/2018 16:12, Christian Mauderer wrote:
> Am 06.08.2018 um 07:31 schrieb Chris Johns:
>> On 06/08/2018 10:51, Chris Johns wrote:
>>> On 05/08/2018 19:39, Christian Mauderer wrote:
 Am 05.08.2018 um 04:00 schrieb Chris Johns:
> Hi,
>
> I have been working on migrating covoar in the rtems-tools repo to DWARF. 
> The
> goal is remove objdump parsing and to get accurate details about the 
> functions
> being covered. This is an unfunded task.
>
> The work has resulted in a close examination of inlined code in RTEMS and 
> what I
> saw alarmed me so I have added a report to the rtems-exeinfo tool in 
> rtems-tools
> (the change is to be posted for review once I get the coverage tests 
> running).
>
> A summary report for hello.exe on RTEMS 5 for SPARC is:
>
> inlined funcs   : 1412
> total funcs : 1956
>  % inline funcs : 72%
>  total size : 174616
> inline size : 81668
>   % inline size : 46%
>
> This is a small application so it could be argued that skews the figures. 
> A
> large C/C++ application built with -O2 running on RTEMS 4.11 ARM reports 
> the
> inline usage as:
>
> inlined funcs   : 10370
> total funcs : 17700
>  % inline funcs : 58%
>  total size : 3066240
> inline size : 1249514
>   % inline size : 40%
>
> This does not seem right to me.
>
> The report is new and there could be issues in the DWARF handling that 
> feeds
> this report however I am posting this to start a discussion on the topic 
> of
> inlining.
>
> I attach the report for hello.exe. The `-i` option generates the inline 
> report.
>
> The first section is a summary showing the total number of functions in 
> the
> executable that have machine code and are flagged as inline. The report 
> lists
> the percentage of functions that are inlined and the percentage of 
> machine code
> that is inlined. The values seem high to me.
>
> The second table lists inline functions that are repeated sorted from the
> largest foot print to the smallest. The first column the total size of 
> machine
> code in the executable and the second column the number of instances.
>
> The third table is the list of inline functions sorted from largest 
> machine code
> footprint to smallest. The second column are flags of which there is one. 
> A `E`
> indicates the inline function is also external which means the compiler 
> has
> created an external reference to this function, ie an address-of is being 
> taken.
> The third column is the address in the executable so you can take a look 
> with
> objdump at the machine code.
>
> We need to ask some important question in relation to inlining. It is 
> cheap to
> add and we all feel the code we add needs to be fast and needs to be 
> inlined but
> does it really need to be inlined?
>
> Some pieces of code do need to be inlined and the overhead is just that an
> overhead, for example in the large C/C++ application there is a low level
> volatile hardware write routing with close to 300 instances and a code 
> size of
> 10K. This code needs to be inlined for performance reasons but should the 
> size
> on average be 40 bytes, I doubt it.
>
> Can we be more judicious with our use of the inline keyword?
>
> Is the performance gain we really expect or is the actual overhead of a 
> call
> frame not worth saving?
>
> What are the real costs of inlining a piece of code? It adds size to the
> executable and depending on the code being inlined it complicates coverage
> analysis be adding extra branch points.
>
> The metrics to determine what should be inlined is complicated and I do 
> not
> think we have a suitable policy in place. I believe it is time we to 
> create one.
>
> The issue is not limited to our code, gcc, newlib and libstdc++ seem to 
> have
> some code that should be looked at more closely. For example 
> __udivmoddi4, and
> __sprint_r.
>
> Chris
>
>

 Hello Chris,

 I just took a look at one of the first function in your list: __sprint_r

 https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdio/vfprintf.c;h=c4bf2dbe31da64462ecccec97c8e901e4ffadd44;hb=HEAD#l403

 As far as I can see, there is no explicit inline key word for that
 function. So in that case, the compiler decided that it would be a good
 idea to inline that function.
>>>
>>> Thanks and yes. At this point in time I cannot tell what is happening and I 
>>> am
>>> not sure the tool is reporting accurate data, I need to investigate.
>>
>> I have updated the tool and report to show which inline functions 

Re: [PATCH] rfs: Remove erroneous call of rtems_disk_release()

[Sebastian Huber]

Hello Chris,

this needs a back port to 4.11 and 4.10.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] rfs: Remove erroneous call of rtems_disk_release()

[Sebastian Huber]

The function rtems_rfs_buffer_sync() erroneously calls
rtems_disk_release(). This screws up the reference counting of the disk.

Update #3484.
---
 cpukit/libfs/src/rfs/rtems-rfs-buffer.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/cpukit/libfs/src/rfs/rtems-rfs-buffer.c 
b/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
index 33beb54700..4a66840b17 100644
--- a/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
+++ b/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
@@ -397,7 +397,6 @@ rtems_rfs_buffer_sync (rtems_rfs_file_system* fs)
   rtems_status_text (sc));
 result = EIO;
   }
-  rtems_disk_release (fs->disk);
 #else
   if (fsync (fs->device) < 0)
   {
-- 
2.13.7

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Inlined code

[Christian Mauderer]

Am 06.08.2018 um 07:31 schrieb Chris Johns:
> On 06/08/2018 10:51, Chris Johns wrote:
>> On 05/08/2018 19:39, Christian Mauderer wrote:
>>> Am 05.08.2018 um 04:00 schrieb Chris Johns:
 Hi,

 I have been working on migrating covoar in the rtems-tools repo to DWARF. 
 The
 goal is remove objdump parsing and to get accurate details about the 
 functions
 being covered. This is an unfunded task.

 The work has resulted in a close examination of inlined code in RTEMS and 
 what I
 saw alarmed me so I have added a report to the rtems-exeinfo tool in 
 rtems-tools
 (the change is to be posted for review once I get the coverage tests 
 running).

 A summary report for hello.exe on RTEMS 5 for SPARC is:

 inlined funcs   : 1412
 total funcs : 1956
  % inline funcs : 72%
  total size : 174616
 inline size : 81668
   % inline size : 46%

 This is a small application so it could be argued that skews the figures. A
 large C/C++ application built with -O2 running on RTEMS 4.11 ARM reports 
 the
 inline usage as:

 inlined funcs   : 10370
 total funcs : 17700
  % inline funcs : 58%
  total size : 3066240
 inline size : 1249514
   % inline size : 40%

 This does not seem right to me.

 The report is new and there could be issues in the DWARF handling that 
 feeds
 this report however I am posting this to start a discussion on the topic of
 inlining.

 I attach the report for hello.exe. The `-i` option generates the inline 
 report.

 The first section is a summary showing the total number of functions in the
 executable that have machine code and are flagged as inline. The report 
 lists
 the percentage of functions that are inlined and the percentage of machine 
 code
 that is inlined. The values seem high to me.

 The second table lists inline functions that are repeated sorted from the
 largest foot print to the smallest. The first column the total size of 
 machine
 code in the executable and the second column the number of instances.

 The third table is the list of inline functions sorted from largest 
 machine code
 footprint to smallest. The second column are flags of which there is one. 
 A `E`
 indicates the inline function is also external which means the compiler has
 created an external reference to this function, ie an address-of is being 
 taken.
 The third column is the address in the executable so you can take a look 
 with
 objdump at the machine code.

 We need to ask some important question in relation to inlining. It is 
 cheap to
 add and we all feel the code we add needs to be fast and needs to be 
 inlined but
 does it really need to be inlined?

 Some pieces of code do need to be inlined and the overhead is just that an
 overhead, for example in the large C/C++ application there is a low level
 volatile hardware write routing with close to 300 instances and a code 
 size of
 10K. This code needs to be inlined for performance reasons but should the 
 size
 on average be 40 bytes, I doubt it.

 Can we be more judicious with our use of the inline keyword?

 Is the performance gain we really expect or is the actual overhead of a 
 call
 frame not worth saving?

 What are the real costs of inlining a piece of code? It adds size to the
 executable and depending on the code being inlined it complicates coverage
 analysis be adding extra branch points.

 The metrics to determine what should be inlined is complicated and I do not
 think we have a suitable policy in place. I believe it is time we to 
 create one.

 The issue is not limited to our code, gcc, newlib and libstdc++ seem to 
 have
 some code that should be looked at more closely. For example __udivmoddi4, 
 and
 __sprint_r.

 Chris


>>>
>>> Hello Chris,
>>>
>>> I just took a look at one of the first function in your list: __sprint_r
>>>
>>> https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdio/vfprintf.c;h=c4bf2dbe31da64462ecccec97c8e901e4ffadd44;hb=HEAD#l403
>>>
>>> As far as I can see, there is no explicit inline key word for that
>>> function. So in that case, the compiler decided that it would be a good
>>> idea to inline that function.
>>
>> Thanks and yes. At this point in time I cannot tell what is happening and I 
>> am
>> not sure the tool is reporting accurate data, I need to investigate.
> 
> I have updated the tool and report to show which inline functions are:
> 
>  - inlined by compiler
>  - declared inline and not inlined
>  - declared inline and inlined
> 
> I have also fixed a quick hack I had where the size was the span from the low 
> PC
> to the high PC,