Skip to content

W
White Rabbit Switch - Software
Commit dfb35a1e authored by Alessandro Rubini's avatar Alessandro Rubini
Browse files
Options

doc: wrs-todo update to current status 

Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
parent 31cb878e
Hide whitespace changes
Inline Side-by-side
Showing with 19 additions and 27 deletions
doc/wrs-todo.in
View file @ dfb35a1e
......@@ -35,7 +35,7 @@
@setchapternewpage off
@set update-month December 2014
@set update-month January 2015
@c the release name below is substituted at build time
@set release __RELEASE_GIT_ID__
......@@ -109,6 +109,9 @@ of fact, the @i{snmpd} process is currently more than 1M in RAM footprint.
of history in @i{barebox} is unacceptable (if you @i{ssh} in twice,
the up-arrow will show interference between shells).
@item We may consider moving this package to a real buildroot thing,
and submit upstream.
@item We need a way to set a root password during configuration.
@end itemize
......@@ -142,17 +145,17 @@ waiting for the boot loader to be sent to RAM from USB.
Unfortunately this means writing the ``device tree'' crap for our board,
as everything nowadays is device-tree-based. Which in my opinion has
been designed by our competitors, to kill us slowly and painfully.
In addition, our patches must be ported forward.
In addition, our patches must be ported forward. A patch-set for 3.14
is currently work in progress.
@item The @i{wr-nic} driver is very similar to what we run for the SPEC,
which is not surprising because the gateware is basically the same.
We should make the two drivers identical. I did some initial work
on this, available in the @i{wr-nic-130207} branch, but it must be
completed (a similar branch exists in @i{spec-sw}, changing the
@t{wr-nic.ko} to use the same code base as the switch.
we went forward in merging it with the one in @i{spec-sw} but a few
lines are still different. Unifying will allow using a driver
for the gateware block, likely based on SDB.
@item We should push upstream the generic changes we made to the kernel,
like increasing @t{NR_IRQ} and exporting symbols for externally-loaded
like increasing @t{NR_IRQ} (likey not needed, as we have sparse interrupts
in more recent kernel trees) and exporting symbols for externally-loaded
@t{irq_chip} drivers.
@end itemize
......@@ -203,18 +206,11 @@ As a side effect, a file-based interface allows off-switch simulation
and development (which includes simulating errors to test error paths in
the actual code).
@item While merging the libraries, we should seriously audit them.
Some functions do nothing, some are never called, and some are only
used withing the @i{hal} process, so there's no need to have them
public in an exported library. The library code rusted over the years,
and we can't trust it any more without some clean up. I'm personally
scared every time I look in that code base.
@item Whenever @i{ipc} is used for actions, rather than just status passing,
which is now shmem-based,
we should audit the processes to ensure the are based on @i{select}
rather than a timely poll. Actually, the HAL process is using quite
a lot of cpu time, and it could do much better.
@item We started auditing and cleaning up the libraries
(now one library only: @i{libwr}) but there's much work to be done here.
The current situation works, but we want to make the library
understandable and maintainable: the library code rusted over the years,
and we can't trust it any more without some clean up.
@item The @i{rtud} should be seriously audited and simplified. The
interface with gateware is now simpler than it was, but software still
......@@ -223,8 +219,9 @@ is overkill, and the program could benefit from a simplification.
@item The SFP code needs to be cleaned up. There is unsafe string
management in 16-wide non-terminated fields, and we don't really
report all the information we have (we should copy to shmem so to
get it out, at least). Also, using the device name without the vendor
report all the information we have (we should copy all SFP
information to shmem: we are almost there but not completely).
Moreover, using the device name without the vendor
name is unsafe: some vendors use generic device names.
@item The @t{TRACE} support it not really working. We have serious
......@@ -232,11 +229,6 @@ warning messages that were never reported. We should really print
everything to stderr and let syslog manage it (according to user
configuration: this is already in dot-config).
@item Default values, when configuration is missing, are badly chosen.
For example, @i{alpha} is always positive for an unknown SFP, but we
should rather have zero (or a positive/negative thing according the
the wavelength, if known).
@end itemize
@c ##########################################################################
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment