Re: Scheduled Transfer Protocol on Linux

From: Karen Shaeffer (shaeffer@best.com)
Date: Sun Feb 13 2000 - 14:52:52 EST


On Sun, Feb 13, 2000 at 09:00:20AM -0500, Brandon S. Allbery KF8NH wrote:
> In message <20000212205125.A1370@best.com>, Karen Shaeffer writes:
>
> | And you'll note that those R&D programs are not entertaining the idea of
> | _welding_ a general purpose processor on to the backend core processor. What
> +--->8
>
> Allow me to advance a different analysis: the proposal currently on the
> table is *no longer research*. I recently saw an ad in a magazine for
> one... 10GB (IIRC) disk + ARMLinux, plug into the network and use as a
> standalone NFS/Samba server, or run a webserver on it, etc. NASD has moved
> beyond that except insofar as they could be components. :)
>
> --
> brandon s. allbery os/2,linux,solaris,perl allbery@kf8nh.apk.net
---end quoted text---

I have no problem with the feasibility of taking a disk drive and adding an
embedded general purpose processor to make an integrated system. It should
be overtly obvious to anyone this is possible and maybe even a winning
product.

The original proposal from Larry McVoy was to replace the electronics now
inside a disk drive with an embedded general purpose processor. I'll repeat
that here to refresh your memory:

<quote from Larry McVoy>

This is cool but what I want is both more cool and more mundane.
It's the mundane aspect that makes it cool. Here's the picture:

Imagine that cheapo IDIE drives could be bought soon with 100BaseT and
not so soon with GigEth over copper connecters. They cost about $100
more than your current IDE drives (which are essentially free :-)

Imagine Linux with STP in the kernel on _both_ ends of the connection.
On the disk drive, the embedded 680x0 is gone, replaced with an embedded
Celeron (or whatever is cheap, maybe Transmeta wants to play in this
space; hmm, that's a cool idea, maybe I should call Ditzel).

Linux on the disk drive is not as far fetched as you might think - the
drives already have two processors out there, the analogue thing that
runs the arm and the more normal thing that manages the cache, does
any protocol, whatever. Lift the existing normal one, drop in a Celeron,
add a little memory and let Linux manage the cache. And run STP, HTTP,
NFS, SMB, etc. You know have an IP address problem, but that's what test
networks are for (or the 127.0.0.0 net, there are a bunch of spares).

</quote>

Now I have been addressing that proposal as not feasible. And it is not.
Note he is specifically stating he envisions the embedded general purpose
controller actually replacing the standard disk drive electronics. See my
prior posts in this thread for why this is not feasible. As often happens
in these mailing list threads, the posts tend to lose the focus rather
quickly...

The product where you __ADD__ an embedded system to a disk drive is not something
for an R&D lab. It's a no brainer, you just need a PCB layout engineer and a
few design engineers to put it together. Cost and market size is another
issue... I'm not discussing that and have no intention of doing so.

Karen

-- 
----
  Karen Shaeffer
  Neuralscape; (831) 426-8547
  Santa Cruz, Ca. 95060
  shaeffer@neuralscape.com  http://www.neuralscape.com
-------------------------------------------------------

- 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/



This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:25 EST