As Greg said, this is a traditional way. I'd maybe allow dummy reads/writes if
permissions allow, but keep that logic in vfs by checking if the pointer is
initialized. Then you don't need to provide the dummy implementation in every
driver.
Petro Karashchenko kirjoitti lauantai 2. huhtikuuta 2
Hello Gregory,
Do you recommend not to allow registration of a driver that does not have
read method and make a requirement for the driver to provide at least dummy
read?
Best regards,
Petro
On Fri, Apr 1, 2022, 9:48 PM Gregory Nutt wrote:
>
> > One option, conforming standard, would be that y
> 2) ORTE Data-Distribution Service (DDS)
[...]
> But speak with him on continuation of the work or even
> in general has been intentionally and hard way blocked by professor
> Zdenek Hanzalek and doctor Michal Sojka later when Jirka was
> allocated at proprietary NVIDIA work at university for co
On Sat, Apr 2, 2022 at 3:16 AM Jukka Laitinen wrote:
> I am not the author there, just feel that the process is not fair for the
> author.
>
> The PR has over 300 comments, and they come in bunches of 20, every day
> one bunch more. Most of them are just of type "please replace xxxyyy with
> xxx_
Fixed!
On 4/1/22, Jukka Laitinen wrote:
> I am not the author there, just feel that the process is not fair for the
> author.
>
> The PR has over 300 comments, and they come in bunches of 20, every day one
> bunch more. Most of them are just of type "please replace xxxyyy with
> xxx_yyy", or "ple
I am not the author there, just feel that the process is not fair for the
author.
The PR has over 300 comments, and they come in bunches of 20, every day one
bunch more. Most of them are just of type "please replace xxxyyy with xxx_yyy",
or "please move these lines 20 lines above". That is, pur
One option, conforming standard, would be that you just always give O_RDWR
(same flags as what linux devices have), but then when calling read/write you
check if the pointer is non-null. If the driver doesn't define read or write,
those operations are allowed on the device, but act as no-op.
Hi Jukka,
I think everybody want RISC-V with Kernel mode support on NuttX.
Sometimes we get really angry because some comments seem too picky,
but we need to believe in the "The Wisdom of Crowds" (i.e.:
https://www.youtube.com/watch?v=Qfh-k9P8ZPI )
So, instead getting mad about it, please try to
Hi,
If RISC-V S-mode and CONFIG_BUILD_KERNEL support is not wanted into NuttX,
please say it out loud instead of playing unfair review games.
The team has better things to do than re-write code letter-by letter via code
review, week after week. The code is good quality and working, and is d
One option, conforming standard, would be that you just always give O_RDWR
(same flags as what linux devices have), but then when calling read/write you
check if the pointer is non-null. If the driver doesn't define read or write,
those operations are allowed on the device, but act as no-op.
-
In my opinion 0, if you are asking that, but it is strictly not conforming the
standard.
Posix says that "Applications shall specify exactly one of the first five...",
so there is no correct standard conforming way. All five would be wrong, imho.
-Jukka
Petro Karashchenko kirjoitti perjantai 1
Yes Jukka what you are saying is absolutely correct. The main item under
discussion are the drivers that are pure ioctl (that means do not have
neither read nor write handlers). Should RD or WR flag be passed to open
call in such case of or 0 should be passed.
Best regards,
Petro
On Fri, Apr 1, 2
Different posix implementations have different values for these flags, so I
think it is ok not to have the same as what linux has.
Posix (2017) specifies thar exactly one of the following is provided for open:
O_EXEC, O_RDWR, O_RDONLY, O_SEARCH and O_WRONLY, and other flags are bitwise
OR'd to
More about it here:
https://stackoverflow.com/questions/61923703/how-to-make-sense-of-o-rdonly-0
So, I agree with the comment that said "calling it flag is misnomer
and misleading"
On Unix/Linux O_RDONLY | O_WRONLY != O_RDWR, on NuttX is it explicitly this way:
#define O_RDWR (O_RDOK|O_WROK
Yeah,
Probably this is the case. So when it is understood we need to think how to
fix it :)
Best regards,
Petro
пт, 1 квіт. 2022 р. о 17:41 Alan Carvalho de Assis пише:
> Hmm, I think oflag equal 0 on Unix(so MacOS)/Linux works because of it:
>
> #define O_RDONLY
>
> So, in fac
Hmm, I think oflag equal 0 on Unix(so MacOS)/Linux works because of it:
#define O_RDONLY
So, in fact on Linux/Mac when we are opening a file with oflag 0 we
are opening it for reading only.
On NuttX the value 0 is not defined, O_RDONLY is 1:
#define O_RDONLY(1 << 0)
BR,
Al
Ok. I will update the code example and come back later with some answers.
On Fri, Apr 1, 2022, 5:32 PM Xiang Xiao wrote:
> We need to try some ioctl with read/write some driver(e.g. serial driver
> baud) internal state.
>
>
> On Fri, Apr 1, 2022 at 10:05 PM Petro Karashchenko <
> petro.karashche
We need to try some ioctl with read/write some driver(e.g. serial driver
baud) internal state.
On Fri, Apr 1, 2022 at 10:05 PM Petro Karashchenko <
petro.karashche...@gmail.com> wrote:
> Hello,
>
> Here I'm talking not about driver registration permission, but more about
> the "oflag" parameter
Hello,
Here I'm talking not about driver registration permission, but more about
the "oflag" parameter to "open()" call.
I just tried a quick example on MAC
#include
#include
int main(void)
{
int fd = open("test.txt", 0);
if (fd < 0)
printf("A\n");
else
printf("B\n");
return
On Wed, Mar 30, 2022 at 12:50 PM Alin Jerpelea wrote:
>
> Hello all,
>
>
> Apache NuttX (Incubating) 10.3.0 RC0 has been staged under [1] and it's
> time to vote on accepting it for release. If approved we will seek
> final release approval from the IPMC. Voting will be open for 72hr.
>
> A minimu
Hi Lup,
Nice work! Kudos!!!
Did you manually change the Red to Blue color? If you are running the
default LVGL 7.3 demo the color should be Red see:
ESP32 with NuttX:
https://www.youtube.com/watch?v=b2m4LNd29ao
ESP32 with Arduino:
https://www.youtube.com/watch?v=Zq_MZXYbdgI
Maybe your R and B
I think the device file shouldn't be created with permission 000.
Look inside your Linux /dev all device files have RW permission for
root, some give only R for group and others.
So, probably we need to fix the device register creation, not removing
the flag check.
BR,
Alan
On 4/1/22, Xiang Xi
It's better to check ioctl callback too since ioctl means the driver has
the compatibility of read(i)and write(o).
On Fri, Apr 1, 2022 at 9:15 PM Petro Karashchenko <
petro.karashche...@gmail.com> wrote:
> So Alan do you suggest to remove inode_checkflags?
>
> On Fri, Apr 1, 2022, 4:13 PM Alan Ca
So Alan do you suggest to remove inode_checkflags?
On Fri, Apr 1, 2022, 4:13 PM Alan Carvalho de Assis
wrote:
> Hi Petro,
>
> I saw your PR #1117 but I think opening a device file with flag 0 is
> not correct, please see the open man-pages:
>
> alan@dev:/tmp$ man 2 open
>
>The argument f
Hi Petro,
I saw your PR #1117 but I think opening a device file with flag 0 is
not correct, please see the open man-pages:
alan@dev:/tmp$ man 2 open
The argument flags must include one of the following access
modes: O_RDONLY, O_WRONLY, or
O_RDWR. These request opening the fil
cool! congratz! :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
+1
I checked:
1. NOTICE, DISCLAIMER and LICENSE files exist.
2. Incubating in name
3. Can build from source.
Thank you Alin!
On Wed, Mar 30, 2022 at 6:50 PM Alin Jerpelea wrote:
>
> Hello all,
>
>
> Apache NuttX (Incubating) 10.3.0 RC0 has been staged under [1] and it's
> time to vote on accept
Hi,
I want to resume this thread again because after reexamined code carefully
I found that VFS layer has an API
int inode_checkflags(FAR struct inode *inode, int oflags)
{
if (((oflags & O_RDOK) != 0 && !inode->u.i_ops->read) ||
((oflags & O_WROK) != 0 && !inode->u.i_ops->write))
{
28 matches
Mail list logo
