Re: [PATCH v2 2/3] fpga manager: framework core

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Oct 24, 2014 at 3:54 PM, atull <atull@xxxxxxxxxxxxxxxxxxxxx> wrote:
> On Fri, 24 Oct 2014, Pantelis Antoniou wrote:
>
>> Hi Pavel,
>>
>> > On Oct 24, 2014, at 1:52 PM, Pavel Machek <pavel@xxxxxxx> wrote:
>> >
>> > Hi!
>> >
>> >> * /sys/class/fpga_manager/<fpga>/firmware
>> >>  Name of FPGA image file to load using firmware class.
>> >>  $ echo image.rbf > /sys/class/fpga_manager/<fpga>/firmware
>> >
>> > I .. still don't think this is good idea. What about namespaces?
>> > The path corresponds to path in which namespace?
>> >
>
> Hi Pavel,
>
> Sorry if my documentation is too brief here.  The context is the
> firmware class.  The 'image.rbf' is a image file that is located
> on the filesystem in the firmware search patch.
> See Documentation/firmware_class/README.
>
> Basically we need some way of loading a FPGA image to the FPGA.
> I don't think any one way is going to meet everybody's needs so
> I wanted to export enough functions from fpga-mgr.c that other
> interfaces can by built.  I think firmware will work just fine
> for some people and it is great in that it already exists in the
> kernel.
>
> If I missed your point, please let me know.
>
>>
>> FWIW the overlays patchset uses binary configfs attribute to make this work.
>>
>
> Hi Pantelis,
>
> Yes I think you've mentioned that before.  So that would be another
> way of giving a device tree overlay to configfs, right?  I should
> that to the documentation in the patch header.
>
>> >> +int fpga_mgr_write(struct fpga_manager *mgr, const char *buf, size_t count)
>> >> +{
>> >> +  int ret;
>> >> +
>> >> +  if (test_and_set_bit_lock(FPGA_MGR_BUSY, &mgr->flags))
>> >> +          return -EBUSY;
>> >> +
>> >> +  dev_info(mgr->dev, "writing buffer to %s\n", mgr->name);
>> >> +
>> >> +  ret = __fpga_mgr_write(mgr, buf, count);
>> >> +  clear_bit_unlock(FPGA_MGR_BUSY, &mgr->flags);
>> >> +
>> >> +  return ret;
>> >> +}
>> >> +EXPORT_SYMBOL_GPL(fpga_mgr_write);
>> >
>> > Is the EBUSY -- userspace please try again, but you don't know when to
>> > try again -- right interface? I mean, normally kernel would wait, so
>> > that userland does not have to poll?
>> >
>
> Yes, for fpga_mgr_write it may be more useful for this to be
> a blocking call.
>
>> >> +static ssize_t fpga_mgr_firmware_store(struct device *dev,
>> >> +                                 struct device_attribute *attr,
>> >> +                                 const char *buf, size_t count)
>> >> +{
>> >> +  struct fpga_manager *mgr = dev_get_drvdata(dev);
>> >> +  unsigned int len;
>> >> +  char image_name[NAME_MAX];
>> >> +  int ret;
>> >> +
>> >> +  /* lose terminating \n */
>> >> +  strcpy(image_name, buf);
>> >> +  len = strlen(image_name);
>> >> +  if (image_name[len - 1] == '\n')
>> >> +          image_name[len - 1] = 0;
>> >> +
>> >> +  ret = fpga_mgr_firmware_write(mgr, image_name);
>> >> +  if (ret)
>> >> +          return ret;
>> >> +
>> >> +  return count;
>> >> +}
>> >
>> > This shows why the interface is not right... Valid filename may
>> > contain \n, right? It may even end with \n.
>> >
>>
>> I could argue that a valid firmware file is one that's well formed and does not
>> contain those characters.
>>
>> I guess this is only for make echo file >foo work. You could specify that echo -n file >foo is
>> required.
>>
>
> I am accustomed to doing 'echo -n' for most of sysfs anyway.  Once in a
> while I am a bonehead and forget the '-n' and spend a few minutes
> wondering why this thing that worked last week suddenly rejects all
> commands.  I'm just trying to make my user interface a bit user-friendly.
>
> I will take out the '\n' stripping and update the documentation.  I didn't
> realize this would be controversial.

Don't. You're doing the right thing by scrubbing your input. Requiring
'echo -n' is just stupid when it is so easy to make work easily.

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux