You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Petro Karashchenko <pe...@gmail.com> on 2022/01/26 13:06:21 UTC
is CODE keyword still used?
Hello team,
Recently I noticed that some structures in common code use CODE
keyword for pointers to functions and some do not, so I have the
question: is CODE keyword still supported?
Here are few examples:
struct automount_lower_s
{
...
CODE int (*attach)(FAR const struct automount_lower_s *lower,
automount_handler_t isr, FAR void *arg);
CODE void (*enable)(FAR const struct automount_lower_s *lower,
bool enable);
CODE bool (*inserted)(FAR const struct automount_lower_s *lower);
};
vs
struct file_operations
{
int (*open)(FAR struct file *filep);
int (*close)(FAR struct file *filep);
ssize_t (*read)(FAR struct file *filep, FAR char *buffer, size_t buflen);
ssize_t (*write)(FAR struct file *filep, FAR const char *buffer,
size_t buflen);
off_t (*seek)(FAR struct file *filep, off_t offset, int whence);
int (*ioctl)(FAR struct file *filep, int cmd, unsigned long arg);
/* The two structures need not be common after this point */
int (*poll)(FAR struct file *filep, struct pollfd *fds, bool setup);
#ifndef CONFIG_DISABLE_PSEUDOFS_OPERATIONS
int (*unlink)(FAR struct inode *inode);
#endif
};
Will appreciate your feedback.
Best regards,
Petro
Re: is CODE keyword still used?
Posted by Takashi Yamamoto <ya...@midokura.com.INVALID>.
i guess that a problem is the semantics of CODE/FAR/NEAR is not very
well documented.
On Thu, Jan 27, 2022 at 5:21 AM Gregory Nutt <sp...@gmail.com> wrote:
>
> >
> >> Should be nice if we could find a wait to instruct the compiler (or
> >> the building system) to include the typedefed CODE to the pointer
> >> functions automatically, but I don't know if it is possible.
> >>
> >> I think you are all making risky irresponsible changes to fix something
> > that is not broken.
> >
>
> Also, I don't think that you can assume that a pointed-at function resides
> in code ROM. Couldn't it also reside in RAM? I could imagine having FAR
> function pointers and CODE function pointers and we should not limit the
> support.
do you mean they would be "void (CODE *f)(void)" and "void (FAR *f)(void)"
respectively?
Re: is CODE keyword still used?
Posted by Gregory Nutt <sp...@gmail.com>.
>
>> Should be nice if we could find a wait to instruct the compiler (or
>> the building system) to include the typedefed CODE to the pointer
>> functions automatically, but I don't know if it is possible.
>>
>> I think you are all making risky irresponsible changes to fix something
> that is not broken.
>
Also, I don't think that you can assume that a pointed-at function resides
in code ROM. Couldn't it also reside in RAM? I could imagine having FAR
function pointers and CODE function pointers and we should not limit the
support.
>
>
Re: is CODE keyword still used?
Posted by Gregory Nutt <sp...@gmail.com>.
> Should be nice if we could find a wait to instruct the compiler (or
> the building system) to include the typedefed CODE to the pointer
> functions automatically, but I don't know if it is possible.
>
> I think you are all making risky irresponsible changes to fix something
that is not broken.
Re: is CODE keyword still used?
Posted by Takashi Yamamoto <ya...@midokura.com.INVALID>.
On Thu, Jan 27, 2022 at 1:57 AM Alan Carvalho de Assis
<ac...@gmail.com> wrote:
>
> Sorry Petro, I missed that files!
>
> Maybe Greg could explain why it is missing or if it is not necessary.
i'm interested in the answer to this.
>
> Should be nice if we could find a wait to instruct the compiler (or
> the building system) to include the typedefed CODE to the pointer
> functions automatically, but I don't know if it is possible.
>
> BR,
>
> Alan
>
> On 1/26/22, Petro Karashchenko <pe...@gmail.com> wrote:
> > Hello Alan,
> >
> > Maybe you misread the header file. Here are few examples of what is in
> > include/nuttx/fs/fs.h
> > struct file_operations
> > {
> > /* The device driver open method differs from the mountpoint open method
> > */
> >
> > int (*open)(FAR struct file *filep);
> >
> > /* The following methods must be identical in signature and position
> > * because the struct file_operations and struct mountp_operations are
> > * treated like unions.
> > */
> >
> > int (*close)(FAR struct file *filep);
> > ssize_t (*read)(FAR struct file *filep, FAR char *buffer, size_t buflen);
> > ssize_t (*write)(FAR struct file *filep, FAR const char *buffer,
> > size_t buflen);
> > off_t (*seek)(FAR struct file *filep, off_t offset, int whence);
> > int (*ioctl)(FAR struct file *filep, int cmd, unsigned long arg);
> >
> > /* The two structures need not be common after this point */
> >
> > int (*poll)(FAR struct file *filep, struct pollfd *fds, bool setup);
> > #ifndef CONFIG_DISABLE_PSEUDOFS_OPERATIONS
> > int (*unlink)(FAR struct inode *inode);
> > #endif
> > };
> >
> > struct block_operations
> > {
> > int (*open)(FAR struct inode *inode);
> > int (*close)(FAR struct inode *inode);
> > ssize_t (*read)(FAR struct inode *inode, FAR unsigned char *buffer,
> > blkcnt_t start_sector, unsigned int nsectors);
> > ssize_t (*write)(FAR struct inode *inode, FAR const unsigned char
> > *buffer,
> > blkcnt_t start_sector, unsigned int nsectors);
> > int (*geometry)(FAR struct inode *inode, FAR struct geometry
> > *geometry);
> > int (*ioctl)(FAR struct inode *inode, int cmd, unsigned long arg);
> > #ifndef CONFIG_DISABLE_PSEUDOFS_OPERATIONS
> > int (*unlink)(FAR struct inode *inode);
> > #endif
> > };
> >
> > struct mountpt_operations
> > {
> > /* The mountpoint open method differs from the driver open method
> > * because it receives (1) the inode that contains the mountpoint
> > * private data, (2) the relative path into the mountpoint, and (3)
> > * information to manage privileges.
> > */
> >
> > int (*open)(FAR struct file *filep, FAR const char *relpath,
> > int oflags, mode_t mode);
> >
> > /* The following methods must be identical in signature and position
> > * because the struct file_operations and struct mountpt_operations are
> > * treated like unions.
> > */
> >
> > int (*close)(FAR struct file *filep);
> > ssize_t (*read)(FAR struct file *filep, FAR char *buffer, size_t buflen);
> > ssize_t (*write)(FAR struct file *filep, FAR const char *buffer,
> > size_t buflen);
> > off_t (*seek)(FAR struct file *filep, off_t offset, int whence);
> > int (*ioctl)(FAR struct file *filep, int cmd, unsigned long arg);
> >
> > /* The two structures need not be common after this point. The following
> > * are extended methods needed to deal with the unique needs of mounted
> > * file systems.
> > *
> > * Additional open-file-specific mountpoint operations:
> > */
> >
> > int (*sync)(FAR struct file *filep);
> > int (*dup)(FAR const struct file *oldp, FAR struct file *newp);
> > int (*fstat)(FAR const struct file *filep, FAR struct stat *buf);
> > int (*fchstat)(FAR const struct file *filep,
> > FAR const struct stat *buf, int flags);
> > int (*truncate)(FAR struct file *filep, off_t length);
> >
> > /* Directory operations */
> >
> > int (*opendir)(FAR struct inode *mountpt, FAR const char *relpath,
> > FAR struct fs_dirent_s *dir);
> > int (*closedir)(FAR struct inode *mountpt,
> > FAR struct fs_dirent_s *dir);
> > int (*readdir)(FAR struct inode *mountpt,
> > FAR struct fs_dirent_s *dir);
> > int (*rewinddir)(FAR struct inode *mountpt,
> > FAR struct fs_dirent_s *dir);
> >
> > /* General volume-related mountpoint operations: */
> >
> > int (*bind)(FAR struct inode *blkdriver, FAR const void *data,
> > FAR void **handle);
> > int (*unbind)(FAR void *handle, FAR struct inode **blkdriver,
> > unsigned int flags);
> > int (*statfs)(FAR struct inode *mountpt, FAR struct statfs *buf);
> >
> > /* Operations on paths */
> >
> > int (*unlink)(FAR struct inode *mountpt, FAR const char *relpath);
> > int (*mkdir)(FAR struct inode *mountpt, FAR const char *relpath,
> > mode_t mode);
> > int (*rmdir)(FAR struct inode *mountpt, FAR const char *relpath);
> > int (*rename)(FAR struct inode *mountpt, FAR const char *oldrelpath,
> > FAR const char *newrelpath);
> > int (*stat)(FAR struct inode *mountpt, FAR const char *relpath,
> > FAR struct stat *buf);
> > int (*chstat)(FAR struct inode *mountpt, FAR const char *relpath,
> > FAR const struct stat *buf, int flags);
> > };
> >
> > Those structures contain exactly function pointers.
> >
> > Best regards,
> > Petro
> >
> > ср, 26 січ. 2022 р. о 16:05 Alan Carvalho de Assis <ac...@gmail.com>
> > пише:
> >>
> >> Hey Petro,
> >>
> >> The CODE is used on function pointers, so I think it is ok in the FS
> >> code.
> >>
> >> BR,
> >>
> >> Alan
> >>
> >> On 1/26/22, Petro Karashchenko <pe...@gmail.com> wrote:
> >> > Hello Alan,
> >> >
> >> > Yeah, I see that. But since CODE is missing for the most of the
> >> > pointers to functions in common code I just wonder how that platform
> >> > works.
> >> > None of FS operations in include/nuttx/fs/fs.h have CODE. Does this
> >> > mean that Z80, Z180 and Z16/ZNEO do not use FS as all?
> >> >
> >> > And another question is: Should we add CODE to function pointers in
> >> > common
> >> > code?
> >> >
> >> > Best regards,
> >> > Petro
> >> >
> >> > ср, 26 січ. 2022 р. о 15:21 Alan Carvalho de Assis <ac...@gmail.com>
> >> > пише:
> >> >>
> >> >> Hi Petro,
> >> >>
> >> >> It is used by Z80, Z180 and Z16/ZNEO, see include/nuttx/compiler.h for
> >> >> reference.
> >> >>
> >> >> BR,
> >> >>
> >> >> Alan
> >> >>
> >> >> On 1/26/22, Petro Karashchenko <pe...@gmail.com> wrote:
> >> >> > Hello team,
> >> >> >
> >> >> > Recently I noticed that some structures in common code use CODE
> >> >> > keyword for pointers to functions and some do not, so I have the
> >> >> > question: is CODE keyword still supported?
> >> >> > Here are few examples:
> >> >> > struct automount_lower_s
> >> >> > {
> >> >> > ...
> >> >> > CODE int (*attach)(FAR const struct automount_lower_s *lower,
> >> >> > automount_handler_t isr, FAR void *arg);
> >> >> > CODE void (*enable)(FAR const struct automount_lower_s *lower,
> >> >> > bool enable);
> >> >> > CODE bool (*inserted)(FAR const struct automount_lower_s *lower);
> >> >> > };
> >> >> > vs
> >> >> > struct file_operations
> >> >> > {
> >> >> > int (*open)(FAR struct file *filep);
> >> >> > int (*close)(FAR struct file *filep);
> >> >> > ssize_t (*read)(FAR struct file *filep, FAR char *buffer, size_t
> >> >> > buflen);
> >> >> > ssize_t (*write)(FAR struct file *filep, FAR const char *buffer,
> >> >> > size_t buflen);
> >> >> > off_t (*seek)(FAR struct file *filep, off_t offset, int whence);
> >> >> > int (*ioctl)(FAR struct file *filep, int cmd, unsigned long
> >> >> > arg);
> >> >> >
> >> >> > /* The two structures need not be common after this point */
> >> >> >
> >> >> > int (*poll)(FAR struct file *filep, struct pollfd *fds, bool
> >> >> > setup);
> >> >> > #ifndef CONFIG_DISABLE_PSEUDOFS_OPERATIONS
> >> >> > int (*unlink)(FAR struct inode *inode);
> >> >> > #endif
> >> >> > };
> >> >> >
> >> >> > Will appreciate your feedback.
> >> >> >
> >> >> > Best regards,
> >> >> > Petro
> >> >> >
> >> >
> >
Re: is CODE keyword still used?
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
Sorry Petro, I missed that files!
Maybe Greg could explain why it is missing or if it is not necessary.
Should be nice if we could find a wait to instruct the compiler (or
the building system) to include the typedefed CODE to the pointer
functions automatically, but I don't know if it is possible.
BR,
Alan
On 1/26/22, Petro Karashchenko <pe...@gmail.com> wrote:
> Hello Alan,
>
> Maybe you misread the header file. Here are few examples of what is in
> include/nuttx/fs/fs.h
> struct file_operations
> {
> /* The device driver open method differs from the mountpoint open method
> */
>
> int (*open)(FAR struct file *filep);
>
> /* The following methods must be identical in signature and position
> * because the struct file_operations and struct mountp_operations are
> * treated like unions.
> */
>
> int (*close)(FAR struct file *filep);
> ssize_t (*read)(FAR struct file *filep, FAR char *buffer, size_t buflen);
> ssize_t (*write)(FAR struct file *filep, FAR const char *buffer,
> size_t buflen);
> off_t (*seek)(FAR struct file *filep, off_t offset, int whence);
> int (*ioctl)(FAR struct file *filep, int cmd, unsigned long arg);
>
> /* The two structures need not be common after this point */
>
> int (*poll)(FAR struct file *filep, struct pollfd *fds, bool setup);
> #ifndef CONFIG_DISABLE_PSEUDOFS_OPERATIONS
> int (*unlink)(FAR struct inode *inode);
> #endif
> };
>
> struct block_operations
> {
> int (*open)(FAR struct inode *inode);
> int (*close)(FAR struct inode *inode);
> ssize_t (*read)(FAR struct inode *inode, FAR unsigned char *buffer,
> blkcnt_t start_sector, unsigned int nsectors);
> ssize_t (*write)(FAR struct inode *inode, FAR const unsigned char
> *buffer,
> blkcnt_t start_sector, unsigned int nsectors);
> int (*geometry)(FAR struct inode *inode, FAR struct geometry
> *geometry);
> int (*ioctl)(FAR struct inode *inode, int cmd, unsigned long arg);
> #ifndef CONFIG_DISABLE_PSEUDOFS_OPERATIONS
> int (*unlink)(FAR struct inode *inode);
> #endif
> };
>
> struct mountpt_operations
> {
> /* The mountpoint open method differs from the driver open method
> * because it receives (1) the inode that contains the mountpoint
> * private data, (2) the relative path into the mountpoint, and (3)
> * information to manage privileges.
> */
>
> int (*open)(FAR struct file *filep, FAR const char *relpath,
> int oflags, mode_t mode);
>
> /* The following methods must be identical in signature and position
> * because the struct file_operations and struct mountpt_operations are
> * treated like unions.
> */
>
> int (*close)(FAR struct file *filep);
> ssize_t (*read)(FAR struct file *filep, FAR char *buffer, size_t buflen);
> ssize_t (*write)(FAR struct file *filep, FAR const char *buffer,
> size_t buflen);
> off_t (*seek)(FAR struct file *filep, off_t offset, int whence);
> int (*ioctl)(FAR struct file *filep, int cmd, unsigned long arg);
>
> /* The two structures need not be common after this point. The following
> * are extended methods needed to deal with the unique needs of mounted
> * file systems.
> *
> * Additional open-file-specific mountpoint operations:
> */
>
> int (*sync)(FAR struct file *filep);
> int (*dup)(FAR const struct file *oldp, FAR struct file *newp);
> int (*fstat)(FAR const struct file *filep, FAR struct stat *buf);
> int (*fchstat)(FAR const struct file *filep,
> FAR const struct stat *buf, int flags);
> int (*truncate)(FAR struct file *filep, off_t length);
>
> /* Directory operations */
>
> int (*opendir)(FAR struct inode *mountpt, FAR const char *relpath,
> FAR struct fs_dirent_s *dir);
> int (*closedir)(FAR struct inode *mountpt,
> FAR struct fs_dirent_s *dir);
> int (*readdir)(FAR struct inode *mountpt,
> FAR struct fs_dirent_s *dir);
> int (*rewinddir)(FAR struct inode *mountpt,
> FAR struct fs_dirent_s *dir);
>
> /* General volume-related mountpoint operations: */
>
> int (*bind)(FAR struct inode *blkdriver, FAR const void *data,
> FAR void **handle);
> int (*unbind)(FAR void *handle, FAR struct inode **blkdriver,
> unsigned int flags);
> int (*statfs)(FAR struct inode *mountpt, FAR struct statfs *buf);
>
> /* Operations on paths */
>
> int (*unlink)(FAR struct inode *mountpt, FAR const char *relpath);
> int (*mkdir)(FAR struct inode *mountpt, FAR const char *relpath,
> mode_t mode);
> int (*rmdir)(FAR struct inode *mountpt, FAR const char *relpath);
> int (*rename)(FAR struct inode *mountpt, FAR const char *oldrelpath,
> FAR const char *newrelpath);
> int (*stat)(FAR struct inode *mountpt, FAR const char *relpath,
> FAR struct stat *buf);
> int (*chstat)(FAR struct inode *mountpt, FAR const char *relpath,
> FAR const struct stat *buf, int flags);
> };
>
> Those structures contain exactly function pointers.
>
> Best regards,
> Petro
>
> ср, 26 січ. 2022 р. о 16:05 Alan Carvalho de Assis <ac...@gmail.com>
> пише:
>>
>> Hey Petro,
>>
>> The CODE is used on function pointers, so I think it is ok in the FS
>> code.
>>
>> BR,
>>
>> Alan
>>
>> On 1/26/22, Petro Karashchenko <pe...@gmail.com> wrote:
>> > Hello Alan,
>> >
>> > Yeah, I see that. But since CODE is missing for the most of the
>> > pointers to functions in common code I just wonder how that platform
>> > works.
>> > None of FS operations in include/nuttx/fs/fs.h have CODE. Does this
>> > mean that Z80, Z180 and Z16/ZNEO do not use FS as all?
>> >
>> > And another question is: Should we add CODE to function pointers in
>> > common
>> > code?
>> >
>> > Best regards,
>> > Petro
>> >
>> > ср, 26 січ. 2022 р. о 15:21 Alan Carvalho de Assis <ac...@gmail.com>
>> > пише:
>> >>
>> >> Hi Petro,
>> >>
>> >> It is used by Z80, Z180 and Z16/ZNEO, see include/nuttx/compiler.h for
>> >> reference.
>> >>
>> >> BR,
>> >>
>> >> Alan
>> >>
>> >> On 1/26/22, Petro Karashchenko <pe...@gmail.com> wrote:
>> >> > Hello team,
>> >> >
>> >> > Recently I noticed that some structures in common code use CODE
>> >> > keyword for pointers to functions and some do not, so I have the
>> >> > question: is CODE keyword still supported?
>> >> > Here are few examples:
>> >> > struct automount_lower_s
>> >> > {
>> >> > ...
>> >> > CODE int (*attach)(FAR const struct automount_lower_s *lower,
>> >> > automount_handler_t isr, FAR void *arg);
>> >> > CODE void (*enable)(FAR const struct automount_lower_s *lower,
>> >> > bool enable);
>> >> > CODE bool (*inserted)(FAR const struct automount_lower_s *lower);
>> >> > };
>> >> > vs
>> >> > struct file_operations
>> >> > {
>> >> > int (*open)(FAR struct file *filep);
>> >> > int (*close)(FAR struct file *filep);
>> >> > ssize_t (*read)(FAR struct file *filep, FAR char *buffer, size_t
>> >> > buflen);
>> >> > ssize_t (*write)(FAR struct file *filep, FAR const char *buffer,
>> >> > size_t buflen);
>> >> > off_t (*seek)(FAR struct file *filep, off_t offset, int whence);
>> >> > int (*ioctl)(FAR struct file *filep, int cmd, unsigned long
>> >> > arg);
>> >> >
>> >> > /* The two structures need not be common after this point */
>> >> >
>> >> > int (*poll)(FAR struct file *filep, struct pollfd *fds, bool
>> >> > setup);
>> >> > #ifndef CONFIG_DISABLE_PSEUDOFS_OPERATIONS
>> >> > int (*unlink)(FAR struct inode *inode);
>> >> > #endif
>> >> > };
>> >> >
>> >> > Will appreciate your feedback.
>> >> >
>> >> > Best regards,
>> >> > Petro
>> >> >
>> >
>
Re: is CODE keyword still used?
Posted by Petro Karashchenko <pe...@gmail.com>.
Hello Alan,
Maybe you misread the header file. Here are few examples of what is in
include/nuttx/fs/fs.h
struct file_operations
{
/* The device driver open method differs from the mountpoint open method */
int (*open)(FAR struct file *filep);
/* The following methods must be identical in signature and position
* because the struct file_operations and struct mountp_operations are
* treated like unions.
*/
int (*close)(FAR struct file *filep);
ssize_t (*read)(FAR struct file *filep, FAR char *buffer, size_t buflen);
ssize_t (*write)(FAR struct file *filep, FAR const char *buffer,
size_t buflen);
off_t (*seek)(FAR struct file *filep, off_t offset, int whence);
int (*ioctl)(FAR struct file *filep, int cmd, unsigned long arg);
/* The two structures need not be common after this point */
int (*poll)(FAR struct file *filep, struct pollfd *fds, bool setup);
#ifndef CONFIG_DISABLE_PSEUDOFS_OPERATIONS
int (*unlink)(FAR struct inode *inode);
#endif
};
struct block_operations
{
int (*open)(FAR struct inode *inode);
int (*close)(FAR struct inode *inode);
ssize_t (*read)(FAR struct inode *inode, FAR unsigned char *buffer,
blkcnt_t start_sector, unsigned int nsectors);
ssize_t (*write)(FAR struct inode *inode, FAR const unsigned char *buffer,
blkcnt_t start_sector, unsigned int nsectors);
int (*geometry)(FAR struct inode *inode, FAR struct geometry
*geometry);
int (*ioctl)(FAR struct inode *inode, int cmd, unsigned long arg);
#ifndef CONFIG_DISABLE_PSEUDOFS_OPERATIONS
int (*unlink)(FAR struct inode *inode);
#endif
};
struct mountpt_operations
{
/* The mountpoint open method differs from the driver open method
* because it receives (1) the inode that contains the mountpoint
* private data, (2) the relative path into the mountpoint, and (3)
* information to manage privileges.
*/
int (*open)(FAR struct file *filep, FAR const char *relpath,
int oflags, mode_t mode);
/* The following methods must be identical in signature and position
* because the struct file_operations and struct mountpt_operations are
* treated like unions.
*/
int (*close)(FAR struct file *filep);
ssize_t (*read)(FAR struct file *filep, FAR char *buffer, size_t buflen);
ssize_t (*write)(FAR struct file *filep, FAR const char *buffer,
size_t buflen);
off_t (*seek)(FAR struct file *filep, off_t offset, int whence);
int (*ioctl)(FAR struct file *filep, int cmd, unsigned long arg);
/* The two structures need not be common after this point. The following
* are extended methods needed to deal with the unique needs of mounted
* file systems.
*
* Additional open-file-specific mountpoint operations:
*/
int (*sync)(FAR struct file *filep);
int (*dup)(FAR const struct file *oldp, FAR struct file *newp);
int (*fstat)(FAR const struct file *filep, FAR struct stat *buf);
int (*fchstat)(FAR const struct file *filep,
FAR const struct stat *buf, int flags);
int (*truncate)(FAR struct file *filep, off_t length);
/* Directory operations */
int (*opendir)(FAR struct inode *mountpt, FAR const char *relpath,
FAR struct fs_dirent_s *dir);
int (*closedir)(FAR struct inode *mountpt,
FAR struct fs_dirent_s *dir);
int (*readdir)(FAR struct inode *mountpt,
FAR struct fs_dirent_s *dir);
int (*rewinddir)(FAR struct inode *mountpt,
FAR struct fs_dirent_s *dir);
/* General volume-related mountpoint operations: */
int (*bind)(FAR struct inode *blkdriver, FAR const void *data,
FAR void **handle);
int (*unbind)(FAR void *handle, FAR struct inode **blkdriver,
unsigned int flags);
int (*statfs)(FAR struct inode *mountpt, FAR struct statfs *buf);
/* Operations on paths */
int (*unlink)(FAR struct inode *mountpt, FAR const char *relpath);
int (*mkdir)(FAR struct inode *mountpt, FAR const char *relpath,
mode_t mode);
int (*rmdir)(FAR struct inode *mountpt, FAR const char *relpath);
int (*rename)(FAR struct inode *mountpt, FAR const char *oldrelpath,
FAR const char *newrelpath);
int (*stat)(FAR struct inode *mountpt, FAR const char *relpath,
FAR struct stat *buf);
int (*chstat)(FAR struct inode *mountpt, FAR const char *relpath,
FAR const struct stat *buf, int flags);
};
Those structures contain exactly function pointers.
Best regards,
Petro
ср, 26 січ. 2022 р. о 16:05 Alan Carvalho de Assis <ac...@gmail.com> пише:
>
> Hey Petro,
>
> The CODE is used on function pointers, so I think it is ok in the FS code.
>
> BR,
>
> Alan
>
> On 1/26/22, Petro Karashchenko <pe...@gmail.com> wrote:
> > Hello Alan,
> >
> > Yeah, I see that. But since CODE is missing for the most of the
> > pointers to functions in common code I just wonder how that platform
> > works.
> > None of FS operations in include/nuttx/fs/fs.h have CODE. Does this
> > mean that Z80, Z180 and Z16/ZNEO do not use FS as all?
> >
> > And another question is: Should we add CODE to function pointers in common
> > code?
> >
> > Best regards,
> > Petro
> >
> > ср, 26 січ. 2022 р. о 15:21 Alan Carvalho de Assis <ac...@gmail.com>
> > пише:
> >>
> >> Hi Petro,
> >>
> >> It is used by Z80, Z180 and Z16/ZNEO, see include/nuttx/compiler.h for
> >> reference.
> >>
> >> BR,
> >>
> >> Alan
> >>
> >> On 1/26/22, Petro Karashchenko <pe...@gmail.com> wrote:
> >> > Hello team,
> >> >
> >> > Recently I noticed that some structures in common code use CODE
> >> > keyword for pointers to functions and some do not, so I have the
> >> > question: is CODE keyword still supported?
> >> > Here are few examples:
> >> > struct automount_lower_s
> >> > {
> >> > ...
> >> > CODE int (*attach)(FAR const struct automount_lower_s *lower,
> >> > automount_handler_t isr, FAR void *arg);
> >> > CODE void (*enable)(FAR const struct automount_lower_s *lower,
> >> > bool enable);
> >> > CODE bool (*inserted)(FAR const struct automount_lower_s *lower);
> >> > };
> >> > vs
> >> > struct file_operations
> >> > {
> >> > int (*open)(FAR struct file *filep);
> >> > int (*close)(FAR struct file *filep);
> >> > ssize_t (*read)(FAR struct file *filep, FAR char *buffer, size_t
> >> > buflen);
> >> > ssize_t (*write)(FAR struct file *filep, FAR const char *buffer,
> >> > size_t buflen);
> >> > off_t (*seek)(FAR struct file *filep, off_t offset, int whence);
> >> > int (*ioctl)(FAR struct file *filep, int cmd, unsigned long arg);
> >> >
> >> > /* The two structures need not be common after this point */
> >> >
> >> > int (*poll)(FAR struct file *filep, struct pollfd *fds, bool
> >> > setup);
> >> > #ifndef CONFIG_DISABLE_PSEUDOFS_OPERATIONS
> >> > int (*unlink)(FAR struct inode *inode);
> >> > #endif
> >> > };
> >> >
> >> > Will appreciate your feedback.
> >> >
> >> > Best regards,
> >> > Petro
> >> >
> >
Re: is CODE keyword still used?
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
Hey Petro,
The CODE is used on function pointers, so I think it is ok in the FS code.
BR,
Alan
On 1/26/22, Petro Karashchenko <pe...@gmail.com> wrote:
> Hello Alan,
>
> Yeah, I see that. But since CODE is missing for the most of the
> pointers to functions in common code I just wonder how that platform
> works.
> None of FS operations in include/nuttx/fs/fs.h have CODE. Does this
> mean that Z80, Z180 and Z16/ZNEO do not use FS as all?
>
> And another question is: Should we add CODE to function pointers in common
> code?
>
> Best regards,
> Petro
>
> ср, 26 січ. 2022 р. о 15:21 Alan Carvalho de Assis <ac...@gmail.com>
> пише:
>>
>> Hi Petro,
>>
>> It is used by Z80, Z180 and Z16/ZNEO, see include/nuttx/compiler.h for
>> reference.
>>
>> BR,
>>
>> Alan
>>
>> On 1/26/22, Petro Karashchenko <pe...@gmail.com> wrote:
>> > Hello team,
>> >
>> > Recently I noticed that some structures in common code use CODE
>> > keyword for pointers to functions and some do not, so I have the
>> > question: is CODE keyword still supported?
>> > Here are few examples:
>> > struct automount_lower_s
>> > {
>> > ...
>> > CODE int (*attach)(FAR const struct automount_lower_s *lower,
>> > automount_handler_t isr, FAR void *arg);
>> > CODE void (*enable)(FAR const struct automount_lower_s *lower,
>> > bool enable);
>> > CODE bool (*inserted)(FAR const struct automount_lower_s *lower);
>> > };
>> > vs
>> > struct file_operations
>> > {
>> > int (*open)(FAR struct file *filep);
>> > int (*close)(FAR struct file *filep);
>> > ssize_t (*read)(FAR struct file *filep, FAR char *buffer, size_t
>> > buflen);
>> > ssize_t (*write)(FAR struct file *filep, FAR const char *buffer,
>> > size_t buflen);
>> > off_t (*seek)(FAR struct file *filep, off_t offset, int whence);
>> > int (*ioctl)(FAR struct file *filep, int cmd, unsigned long arg);
>> >
>> > /* The two structures need not be common after this point */
>> >
>> > int (*poll)(FAR struct file *filep, struct pollfd *fds, bool
>> > setup);
>> > #ifndef CONFIG_DISABLE_PSEUDOFS_OPERATIONS
>> > int (*unlink)(FAR struct inode *inode);
>> > #endif
>> > };
>> >
>> > Will appreciate your feedback.
>> >
>> > Best regards,
>> > Petro
>> >
>
Re: is CODE keyword still used?
Posted by Petro Karashchenko <pe...@gmail.com>.
Hello Alan,
Yeah, I see that. But since CODE is missing for the most of the
pointers to functions in common code I just wonder how that platform
works.
None of FS operations in include/nuttx/fs/fs.h have CODE. Does this
mean that Z80, Z180 and Z16/ZNEO do not use FS as all?
And another question is: Should we add CODE to function pointers in common code?
Best regards,
Petro
ср, 26 січ. 2022 р. о 15:21 Alan Carvalho de Assis <ac...@gmail.com> пише:
>
> Hi Petro,
>
> It is used by Z80, Z180 and Z16/ZNEO, see include/nuttx/compiler.h for
> reference.
>
> BR,
>
> Alan
>
> On 1/26/22, Petro Karashchenko <pe...@gmail.com> wrote:
> > Hello team,
> >
> > Recently I noticed that some structures in common code use CODE
> > keyword for pointers to functions and some do not, so I have the
> > question: is CODE keyword still supported?
> > Here are few examples:
> > struct automount_lower_s
> > {
> > ...
> > CODE int (*attach)(FAR const struct automount_lower_s *lower,
> > automount_handler_t isr, FAR void *arg);
> > CODE void (*enable)(FAR const struct automount_lower_s *lower,
> > bool enable);
> > CODE bool (*inserted)(FAR const struct automount_lower_s *lower);
> > };
> > vs
> > struct file_operations
> > {
> > int (*open)(FAR struct file *filep);
> > int (*close)(FAR struct file *filep);
> > ssize_t (*read)(FAR struct file *filep, FAR char *buffer, size_t buflen);
> > ssize_t (*write)(FAR struct file *filep, FAR const char *buffer,
> > size_t buflen);
> > off_t (*seek)(FAR struct file *filep, off_t offset, int whence);
> > int (*ioctl)(FAR struct file *filep, int cmd, unsigned long arg);
> >
> > /* The two structures need not be common after this point */
> >
> > int (*poll)(FAR struct file *filep, struct pollfd *fds, bool setup);
> > #ifndef CONFIG_DISABLE_PSEUDOFS_OPERATIONS
> > int (*unlink)(FAR struct inode *inode);
> > #endif
> > };
> >
> > Will appreciate your feedback.
> >
> > Best regards,
> > Petro
> >
Re: is CODE keyword still used?
Posted by Gregory Nutt <sp...@gmail.com>.
You would think it should be used with AVR since the data pointer is
typically 16-bits and the instruction pointer is typically 20-24 bits. But
it is not, that is because 1) GCC does support the concept of code vs
data. and 2) a fixed size pointer is used, regardless of actual size of
the address. AVR also does things differently by defining something called
IPTR (memx) in include/nuttx/compiler.h. That should have been called CODE.
In arch/avr/include/types (with include/sys/types.h), a pointer is
typically defined to be 16-bits. That limits the size of the instruction
space to 128Kb (I think) and the data space to 64Kb. There are kludges to
access instruction space beyond this (for example,
https://www.avrfreaks.net/forum/size-pointer-flash-memory-atmega2560).
CODE is the matching name for FAR and NEAR. That former means that the
pointer refers to code and an instruction space pointer should be ubsed and
the latter means that the pointer refers to data and a data space pointer
should used (with a far address or a smaller near address). In
arch/avr/include/types.h you can see that far and near pointers are
defined. Removing CODE while keeping FAR and NEAR would be illogical since
they are part of the same solution.
On Wed, Jan 26, 2022 at 7:22 AM Alan Carvalho de Assis <ac...@gmail.com>
wrote:
> Hi Petro,
>
> It is used by Z80, Z180 and Z16/ZNEO, see include/nuttx/compiler.h for
> reference.
>
> BR,
>
> Alan
>
> On 1/26/22, Petro Karashchenko <pe...@gmail.com> wrote:
> > Hello team,
> >
> > Recently I noticed that some structures in common code use CODE
> > keyword for pointers to functions and some do not, so I have the
> > question: is CODE keyword still supported?
> > Here are few examples:
> > struct automount_lower_s
> > {
> > ...
> > CODE int (*attach)(FAR const struct automount_lower_s *lower,
> > automount_handler_t isr, FAR void *arg);
> > CODE void (*enable)(FAR const struct automount_lower_s *lower,
> > bool enable);
> > CODE bool (*inserted)(FAR const struct automount_lower_s *lower);
> > };
> > vs
> > struct file_operations
> > {
> > int (*open)(FAR struct file *filep);
> > int (*close)(FAR struct file *filep);
> > ssize_t (*read)(FAR struct file *filep, FAR char *buffer, size_t
> buflen);
> > ssize_t (*write)(FAR struct file *filep, FAR const char *buffer,
> > size_t buflen);
> > off_t (*seek)(FAR struct file *filep, off_t offset, int whence);
> > int (*ioctl)(FAR struct file *filep, int cmd, unsigned long arg);
> >
> > /* The two structures need not be common after this point */
> >
> > int (*poll)(FAR struct file *filep, struct pollfd *fds, bool
> setup);
> > #ifndef CONFIG_DISABLE_PSEUDOFS_OPERATIONS
> > int (*unlink)(FAR struct inode *inode);
> > #endif
> > };
> >
> > Will appreciate your feedback.
> >
> > Best regards,
> > Petro
> >
>
Re: is CODE keyword still used?
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
Hi Petro,
It is used by Z80, Z180 and Z16/ZNEO, see include/nuttx/compiler.h for
reference.
BR,
Alan
On 1/26/22, Petro Karashchenko <pe...@gmail.com> wrote:
> Hello team,
>
> Recently I noticed that some structures in common code use CODE
> keyword for pointers to functions and some do not, so I have the
> question: is CODE keyword still supported?
> Here are few examples:
> struct automount_lower_s
> {
> ...
> CODE int (*attach)(FAR const struct automount_lower_s *lower,
> automount_handler_t isr, FAR void *arg);
> CODE void (*enable)(FAR const struct automount_lower_s *lower,
> bool enable);
> CODE bool (*inserted)(FAR const struct automount_lower_s *lower);
> };
> vs
> struct file_operations
> {
> int (*open)(FAR struct file *filep);
> int (*close)(FAR struct file *filep);
> ssize_t (*read)(FAR struct file *filep, FAR char *buffer, size_t buflen);
> ssize_t (*write)(FAR struct file *filep, FAR const char *buffer,
> size_t buflen);
> off_t (*seek)(FAR struct file *filep, off_t offset, int whence);
> int (*ioctl)(FAR struct file *filep, int cmd, unsigned long arg);
>
> /* The two structures need not be common after this point */
>
> int (*poll)(FAR struct file *filep, struct pollfd *fds, bool setup);
> #ifndef CONFIG_DISABLE_PSEUDOFS_OPERATIONS
> int (*unlink)(FAR struct inode *inode);
> #endif
> };
>
> Will appreciate your feedback.
>
> Best regards,
> Petro
>
Re: is CODE keyword still used?
Posted by Petro Karashchenko <pe...@gmail.com>.
Hello Gregory,
The question is more about should we populate it to missing places, or just
keep as is until someone complains (hopefully should never happen).
I'm asking it because automounter structures are equipped with CODE, but
all the FS structures are not and that seems very inconsistent to me. I
mean I can't find a use case with usage of automounter without FS.
Best regards,
Petro
On Wed, Jan 26, 2022, 8:56 PM Gregory Nutt <sp...@gmail.com> wrote:
> It is required for any CPU architecture that has asymmetry in code and data
> space addresses.
>
> It is a bad idea to remove it. There is no benefit to remonving it and
> there is most certainly a downside.
>
> On Wed, Jan 26, 2022 at 7:06 AM Petro Karashchenko <
> petro.karashchenko@gmail.com> wrote:
>
> > Hello team,
> >
> > Recently I noticed that some structures in common code use CODE
> > keyword for pointers to functions and some do not, so I have the
> > question: is CODE keyword still supported?
> > Here are few examples:
> > struct automount_lower_s
> > {
> > ...
> > CODE int (*attach)(FAR const struct automount_lower_s *lower,
> > automount_handler_t isr, FAR void *arg);
> > CODE void (*enable)(FAR const struct automount_lower_s *lower,
> > bool enable);
> > CODE bool (*inserted)(FAR const struct automount_lower_s *lower);
> > };
> > vs
> > struct file_operations
> > {
> > int (*open)(FAR struct file *filep);
> > int (*close)(FAR struct file *filep);
> > ssize_t (*read)(FAR struct file *filep, FAR char *buffer, size_t
> buflen);
> > ssize_t (*write)(FAR struct file *filep, FAR const char *buffer,
> > size_t buflen);
> > off_t (*seek)(FAR struct file *filep, off_t offset, int whence);
> > int (*ioctl)(FAR struct file *filep, int cmd, unsigned long arg);
> >
> > /* The two structures need not be common after this point */
> >
> > int (*poll)(FAR struct file *filep, struct pollfd *fds, bool
> setup);
> > #ifndef CONFIG_DISABLE_PSEUDOFS_OPERATIONS
> > int (*unlink)(FAR struct inode *inode);
> > #endif
> > };
> >
> > Will appreciate your feedback.
> >
> > Best regards,
> > Petro
> >
>
Re: is CODE keyword still used?
Posted by Gregory Nutt <sp...@gmail.com>.
It is required for any CPU architecture that has asymmetry in code and data
space addresses.
It is a bad idea to remove it. There is no benefit to remonving it and
there is most certainly a downside.
On Wed, Jan 26, 2022 at 7:06 AM Petro Karashchenko <
petro.karashchenko@gmail.com> wrote:
> Hello team,
>
> Recently I noticed that some structures in common code use CODE
> keyword for pointers to functions and some do not, so I have the
> question: is CODE keyword still supported?
> Here are few examples:
> struct automount_lower_s
> {
> ...
> CODE int (*attach)(FAR const struct automount_lower_s *lower,
> automount_handler_t isr, FAR void *arg);
> CODE void (*enable)(FAR const struct automount_lower_s *lower,
> bool enable);
> CODE bool (*inserted)(FAR const struct automount_lower_s *lower);
> };
> vs
> struct file_operations
> {
> int (*open)(FAR struct file *filep);
> int (*close)(FAR struct file *filep);
> ssize_t (*read)(FAR struct file *filep, FAR char *buffer, size_t buflen);
> ssize_t (*write)(FAR struct file *filep, FAR const char *buffer,
> size_t buflen);
> off_t (*seek)(FAR struct file *filep, off_t offset, int whence);
> int (*ioctl)(FAR struct file *filep, int cmd, unsigned long arg);
>
> /* The two structures need not be common after this point */
>
> int (*poll)(FAR struct file *filep, struct pollfd *fds, bool setup);
> #ifndef CONFIG_DISABLE_PSEUDOFS_OPERATIONS
> int (*unlink)(FAR struct inode *inode);
> #endif
> };
>
> Will appreciate your feedback.
>
> Best regards,
> Petro
>