My design decision was to cleanly separate the Serial Bus Management
and Transaction Layer from the Link Layer. Bus management and
transaction are common for all hardware except the following case:
> I give you some points why I did this:
> * Consider new, more intelligent hardware. Hardware that does not just
> dump pre-built buffers onto the bus. Writing a driver for this new
> hardware would be _impossible_ in your subsystem.
Yes, but that is IMHO not a reason for reimplementing bus management
and transaction in every hardware driver and thus keeping around
multiple parallel implementations of the same thing. This intelligent
hardware you are talking about probably doesn't need a real subsystem
anyway.
It's like a network card with inbuilt TCP/IP - and that's not supported
by Linux either. Also, including bypasses in a general system is
probably a lot easier than have the same thing implemented in n places
(meaning n places of failure and bugs) just because some little detail
may differ.
> * I presume not all cards use the same DMA packet data format. This could
> seriously bring your subsystem in trouble.
I put quite some thoughts into abstracting the interfaces from the
hardware but to allow hardware optimizations like CRCing and byte
swapping without preferring a type of hardware.
Basically the transmit request passes the hpsb_packet structure to the
hardware driver, which contains a pointer to header data, a pointer to
block data and their sizes. The data is kmalloc'd so you can directly
DMA out of there, the contents can be overwritten for software byte
swapping and there is space for an additional quadlet for software CRC.
Which means it is not dependent on hardware features but is still
easily handable like this function, which sends the next packet on a
Lynx:
/* This must be called with the async_queue_lock held. */
static void send_next_async(struct ti_lynx *lynx)
{
struct ti_pcl pcl;
struct hpsb_packet *packet = lynx->async_queue;
pcl.next = PCL_NEXT_INVALID;
pcl.async_error_next = PCL_NEXT_INVALID;
#ifdef __BIG_ENDIAN
pcl.buffer[0].control = PCL_CMD_XMT | packet->header_size;
#else
pcl.buffer[0].control = PCL_CMD_XMT | packet->header_size
| PCL_BIGENDIAN;
#endif
pcl.buffer[0].pointer = virt_to_bus(packet->header);
pcl.buffer[1].control = PCL_LAST_BUFF | packet->data_size;
pcl.buffer[1].pointer = virt_to_bus(packet->data);
if (!packet->data_be) {
pcl.buffer[1].control |= PCL_BIGENDIAN;
}
put_pcl(lynx, lynx->async_pcl, &pcl);
run_pcl(lynx, lynx->async_pcl_start, 3);
}
That's all there is to sending a new packet on its way. Would this
example be harder to implement on an Adaptec? If so, why?
Ok, this design is not so optimal for chips that do not support
scatter/gather DMA, their drivers would have to copy the data.
> > [snip] You have mostly copied code from the SCSI subsystem
> > without understanding why something is there and have therefore moved
> > all the cruft from the SCSI subsystem (which is badly designed as most
> > developers on the kernel list agree). Reusing something of that would
> > have taken more effort than to just rewrite it and add the missing
> > pieces.
>
> Now on to the second issue:
> Definitely not. I also don't like many things of the SCSI subsystem, but
> anyway
> * I just used what I need and ONLY what I need.
Your own memory allocation system was not neccessary, for example. As
far as I can see memory management is set up early before any other
drivers and unlike SCSI there is no ISA hardware to be supported.
Standard alloc functions should do it nicely.
> * The SCSI subsystem easily allows you to have a mixture of different
> SCSI host adapters in your system. You can have two NCR and one Adaptec
> (e.g.) at the same time. The same applies to 1394. That's why I like it.
No problem, for testing purposes I had two Lynxen in my system and they
both got recognized, initialized and used. No problem for more or
different cards (other than that I don't have any driver other than the
Lynx driver).
> * The SCSI subsystem is stable and proven to do what it is supposed to
> do. If it was THAT bad, why is it still in the kernel?
Noone really likes it, but it is there and rewriting it would be a lot
of work. It's just that nobody yet stood up and volunteered.
> Andreas, I am very glad you are in Linux-1394 business. But don't try to
> reinvent the wheel. If your subsystem is really THAT better, I'll move my
> Adaptec code to your structure ASAP. Quality wins, that's Linux
> development works. But please understand that I _thought_ about what I did
> and by doing everything again you'll make mistakes again I did or even
> other mistakes.
Look, I looked around your code and have a fairly good idea of how it
works. Maybe you should download my patch and take a closer look at it
and see how I do things. Judging from some of your concerns I don't
think you did already.
> Well, I also don't know about your situation and how your effort is
> organized. If you do this as a fulltime job and you are paid for it,
> you'll succeed.
I get paid, but I can not work full time on this.
> Maybe you'll do something that's too much specialized on
> TILynx, but you'll succeed. If you do this in a project which is limited
> on time (similar to what I did) it's critical - You may end up with
> something similar to that already done (maybe better in your opinion), but
> still not finished. Then your boss wants you to do other things.
Heh - not before isochronous transmission works and the whole thing
runs on StrongARM CPUs :-)
--
Andreas E. Bombe <andreas.bombe@munich.netsurf.de>
http://home.pages.de/~andreas.bombe/
RSA 0x886663c9 30 EC 09 73 84 7B 55 83 C4 7A 91 D9 9D C5 4B B0
DSA 0x04880A44 72E5 7031 4414 2EB6 F6B4 4CBD 1181 7032 0488 0A44
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/