RTEMS snapshot ss-20010126 available

[Sergei Organov]

Jake,

I'll take a look at these problems.

Meanwhile, here are some comments:

Jake Janovetz <janovetz at uiuc.edu> writes:
> I've noticed a couple problems with the revised ftpd.  I'm
> trying to track them down...  I figure since Sergei has made
> the most recent modifications, he may know better what changes
> broke them (or if I'm setting things up incorrectly)...
>
> 1. LIST is sometimes sent from a client without a path.  Currently,
>    FTPD expects LIST to have some path.  This should be a matter
>    of checking the number of arguments filled by sscanf.  Using the
>    command "dir ." with ftp clients will fix this problem, but it
>    is inconvenient.

It works for me with my sources (will check it with snapshot).

> 2. Multiple connections sometimes cause a crash.  I ftp with one
>    client and do: "dir ." and get a directory.  A second ftp client
>    (while the first one is open or even after the first one is closed)
>    causes a crash at "dir .".  I don't know the source of this one,
>    yet.

Never encountered this. Need to check with snapshot.

> 3. Hooks are broken (the filename comparison doesn't appear to
>    work anymore -- I put to a hook and it just creates a file with
>    that name.  [this one particularly sucked because I could not
>    download an old code image...  I had to dig out the debug cable
>    and do the gdb song and dance]
>    -- This one occurs because you take the filename and the CWD and
>       build a new filename.  This new filename may/may not match the
>       hook.  Originally, I planned that hooks would not depend on the
>       current working directory.  I don't know what you have in mind
>       for the revised setup.

Is easy to fix, I believe. Will do.

>
> I'm using the following configuration:
>
> struct rtems_ftpd_configuration rtems_ftpd_configuration =
>    {
>       FTPD_TASK_PRIORITY,     /* FTPD task priority */
>       512*1024,               /* Maximum hook 'file' size */
>       0,                      /* Default port */
>       ftpd_hooks,             /* Local ftpd hooks */
>       0,                      /* Use / for home directory */
>       5,                      /* Up to 5 connections */
>       30,                     /* Timeout */
>       0                       /* Read-write access */
>    };
>
>
> Sergei, you mention that the hooks should be dropped in favor
> of RTEMS pseudo-devices.  What are these and how easily can they
> be built and installed?  I'm familiar with the device setup with
> RTEMS, but it is substantially more complex than just associating
> some action with a buffer.  If the pseudo-devices are easy, I'd
> be more than happy to switch to them, but right now, creating
> devices for the hooks I have would be a pain.

As for pseudo-devices, I'm not familiar with them, but I think I understand an
idea. Yes, they are not so simple to create as FTP hooks, but they *are*
general way to do such things and I believe that if general method exists,
there should be very strong reasons to use specific extensions
instead. However, as I already said before, I don't insist on removing FTPD
hooks. I just wanted to drop a notice, and decided to put it into comments in
the FTPD source code.

Sergei.
>
> On Fri, Jan 26, 2001 at 03:03:20PM -0600, Joel Sherrill wrote:
> >
> > As far as I know, this includes every patch/submission sent
> > in during the past few weeks.  It fixes a bug or two in recent
> > snapshots (unix port works again for example).  It also includes
> > the "multiuser" patches.  From my perspective, the core of these
> > patches is a neater organization of the POSIX process related
> > parameters.
> >
> > ftp://ftp.oarcorp.com/pub/rtems/snapshots/rtems/current
> >
> > Enjoy.
> >
> > --
> > Joel Sherrill, Ph.D.             Director of Research & Development
> > joel at OARcorp.com                 On-Line Applications Research
> > Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> >    Support Available             (256) 722-9985