On 4/8/20 4:29 pm, Christian Mauderer wrote:
> Thanks for all Feedback. I integrated the changes suggested by
> Sebastian, cretated the tickets and pushed to 5 and master.
Thank you.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mai
Thanks for all Feedback. I integrated the changes suggested by
Sebastian, cretated the tickets and pushed to 5 and master.
Best regards
Christian
On 04/08/2020 07:41, Chris Johns wrote:
> On 4/8/20 2:22 am, Gedare Bloom wrote:
>>
>> a resource leak is a bug worth back-porting, especially with a
On 4/8/20 2:22 am, Gedare Bloom wrote:
>
> a resource leak is a bug worth back-porting, especially with a simple fix.
>
Ok to push to the 5 branch with a ticket.
Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listin
On Mon, Aug 3, 2020 at 7:18 AM Christian Mauderer
wrote:
>
> PS: Is this a candidate for a backport to 5? How many tickets would I
> have to create for it? One for 5 and one for 6?
>
One for each. Anything put on 5 at this point requires a ticket, and
good practice to add one to 6 also, especiall
On 03/08/2020 15:16, Christian Mauderer wrote:
@@ -270,6 +273,10 @@ typedef struct {
* RTEMS_FILESYSTEM_READ_WRITE,
* &mount_opts
* );
+ *
+ * if (rv != 0) {
+ * mount_opts.converter->handler->destroy(mount_opts.converter);
+ * }
* } el
On 03/08/2020 16:01, Christian Mauderer wrote:
In theory we could. But then we have two cases that look the same to a
user but need a different handling:
1. `mount` failed before reaching rtems_dosfs_initialize (for example
because a wrong file system has been provided or a target directory
doe
Hello Sebastian,
On 03/08/2020 15:57, Sebastian Huber wrote:
> On 03/08/2020 15:16, Christian Mauderer wrote:
>
>> diff --git a/cpukit/libfs/src/dosfs/msdos_init.c
>> b/cpukit/libfs/src/dosfs/msdos_init.c
>> index dc9c76437d..0649258fa7 100644
>> --- a/cpukit/libfs/src/dosfs/msdos_init.c
>> +++ b
On 03/08/2020 15:16, Christian Mauderer wrote:
diff --git a/cpukit/libfs/src/dosfs/msdos_init.c
b/cpukit/libfs/src/dosfs/msdos_init.c
index dc9c76437d..0649258fa7 100644
--- a/cpukit/libfs/src/dosfs/msdos_init.c
+++ b/cpukit/libfs/src/dosfs/msdos_init.c
@@ -102,10 +102,12 @@ int rtems_dosfs_ini
PS: Is this a candidate for a backport to 5? How many tickets would I
have to create for it? One for 5 and one for 6?
On 03/08/2020 15:16, Christian Mauderer wrote:
> Currently if mount fails, a converter isn't destroyed. We have to take
> care of two cases:
>
> 1. The user doesn't provide a conv
Currently if mount fails, a converter isn't destroyed. We have to take
care of two cases:
1. The user doesn't provide a converter.
In this case mounting a dosfs creates a default converter. This patch
makes sure that the converter is destroyed again if mount failes for
this case.
2. The user pro
10 matches
Mail list logo
