On Wed, 2009-07-08 at 14:03 +0200, Øyvind Harboe wrote:
> On Wed, Jul 8, 2009 at 1:55 PM, Zach Welch<z...@superlucidity.net> wrote:
> > On Wed, 2009-07-08 at 12:47 +0200, Øyvind Harboe wrote:
> >> How is the attached patch?
> >
> > The NEWS file details the migration of the installed scripts from
> > $(pkglibdir) to $(pkgdatadir)/scripts; the former should not be used
> > anymore, and custom scripts migrated into $(pkgdatadir)/site/.  This
> > patch will prevent us from forcing this migration, as the old location
> > will continue to be be used.  So it might fix the bug, but it seems bad.
> >
> > However, this particular example shows how our searching for files may
> > be insufficient.  Presently, there is no way to enforce a separation
> > between script files and executable files (if such is desired).
> 
> I don't think we need or want to distinguish between the debug_handler.bin
> and other executables for the target(e.g. at91eb40a flash driver) and scripts.
> 
> > The effect of this would be to allow a site to install read-only binary
> > files that may be used by read-write scripts.  In reality, I think ACLs
> > make this proposition more meaningful, but others can comment on the
> > concept of privilege separation.  Am I taking that idea too far here?
> 
> To the host OS the target executables are not executables, are they?
> 
> > Does this seem sane?
> 
> I don't understand why you need or want to distinguish between target
> executables and scripts.

Let's give this some time to stew.  Clearly, I did not manage to
convince myself entirely, and it's not 0.2.0 material.  I still dislike
the idea of having both pkglibdir and pkgdatadir in the search path.

One distinction between the two would be the scripts run on the host,
but the binaries run on the target.  A parallel might be the difference
between PATH and LDPATH, but I think that comparison is not entirely
right.  I hope this gives some perspective on my thinking here.

Cheers,

Zach

_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to