For what I see in Linux headers
#define O_ACCMODE 0003
#define O_RDONLY
#define O_WRONLY 0001
#define O_RDWR 0002
So 3 seems to be a reserved value and because O_RDONLY in Linux is defined
to 0 the 3 value from Linux is similar to 0 value in NuttX.
Regarding "Yes, for examp
Yes, for example if I want to set the serial device baud rate(TCSETS),
should I open it with O_WRONLY?
Linux has the concept of read IOCTLs and write IOCTLs as determined by
the IOCTL macros. My understanding is that you much provide O_RDONLY or
O_RDWR to use the read IOCTLs and O_WRONLY or
Yes, for example if I want to set the serial device baud rate(TCSETS),
should I open it with O_WRONLY?
On Sat, Apr 2, 2022 at 10:56 PM Gregory Nutt wrote:
> On 4/2/2022 7:03 AM, Xiang Xiao wrote:
> > Many functionality is accessed through ioctl callback, what permission is
> > needed before invo
On 4/2/2022 7:03 AM, Xiang Xiao wrote:
Many functionality is accessed through ioctl callback, what permission is
needed before invoking ioctl?
By permissions, you mean open mode? Per POSIX, O_WRONLY, O_RDONLY, or
O_RDWR is required on any success open call (or O_EXEC or O_SEARCH).
But I did
Here are a few examples of "broken" drivers:
- opamp_fops
- lcddev_fops
- g_pca9635pw_fileops
- g_foc_fops
- notectl_fops
- powerled_fops
- g_rptun_devops
- g_video_fops
The list is not complete. But since the "register_driver()" does not return
an error if both fops read and wr
Hi,
Here are a few examples of "broken" drivers:
- opamp_fops
- lcddev_fops
- g_pca9635pw_fileops
- g_foc_fops
- notectl_fops
- powerled_fops
- g_rptun_devops
- g_video_fops
The list is not complete. But since the "register_driver()" does not return
an error if both fops read and write po
> By doing so we can relax check in inode_checkflags() to:
>
> int inode_checkflags(FAR struct inode *inode, int oflags)
> {
> if ((oflags == 0) ||
> (oflags & O_WROK) != 0 && !inode->u.i_ops->write)
> {
> return -EACCES;
> }
> else
> {
> return OK;
> }
> }
>
>
Many functionality is accessed through ioctl callback, what permission is
needed before invoking ioctl?
On Sat, Apr 2, 2022 at 8:45 PM Gregory Nutt wrote:
> If I understand correctly we can add one single "dummy_read" implementation
> > for all drivers that do not supply the read method. This wi
If I understand correctly we can add one single "dummy_read" implementation
> for all drivers that do not supply the read method. This will ensure that
> O_RDOK is always supported if file permissions allow it.
>
There aren't any file permissions. The entire access is controlled by NULL
and non-N
Hi,
If I understand correctly we can add one single "dummy_read" implementation
for all drivers that do not supply the read method. This will ensure that
O_RDOK is always supported if file permissions allow it. By doing so we can
relax check in inode_checkflags() to:
int inode_checkflags(FAR stru
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
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.
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
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
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))
{
I see. Thank you for the feedback. I will rework changes to get back
read permissions.
Best regards,
Petro
пт, 28 січ. 2022 р. о 14:41 Alan Carvalho de Assis пише:
>
> Hi Petro,
>
> The read permission is needed even when you just want to open a file:
>
> $ vim noreadfile
>
> $ chmod noread
Hi Petro,
The read permission is needed even when you just want to open a file:
$ vim noreadfile
$ chmod noreadfile
$ ls -l noreadfile
-- 1 user user 5 jan 28 09:24 noreadfile
$ cat noreadfile
cat: noreadfile: Permission denied
You can even try to create a C program just to open
On Fri, Jan 28, 2022 at 6:05 PM Petro Karashchenko <
petro.karashche...@gmail.com> wrote:
> Hello,
>
> Yes, but how does this relate to "" mode for "register_driver()"?
>
"" means no read/write/execute permission, I can't imagine any real
driver could benefit from it.
> Maybe you can de
Hello,
Yes, but how does this relate to "" mode for "register_driver()"?
Maybe you can describe some use case so it will become more clear?
Currently ioctl works fine if driver is registered with "" permission mode.
Best regards,
Petro
пт, 28 січ. 2022 р. о 11:39 Xiang Xiao пише:
>
> If
If we want to do the correct permission check, the ioctl handler needs to
check R/W bit by itself based on how the ioctl is implemented.
Or follow up how Linux encode the needed permission into each IOCTL:
https://github.com/torvalds/linux/blob/master/include/uapi/asm-generic/ioctl.h#L85-L91
and le
Hello team,
Recently I have noticed that there are many places in code where
register_driver() is called with non-zero mode with file operation
structures that have neither read nor write APIs implemented. For
example "ret = register_driver(path, &opamp_fops, 0444, dev);" while
opamp_fops has only
34 matches
Mail list logo
