首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

linux驱动开发中copy_from_user open read write等常用函数总结

函数定义: int open( const char * pathname, int flags); int open( const char * pathname,int flags, mode_t mode); 参数说明: pathname :文件的名称,可以包含(绝对和相对)路径 flags:文件打开模式 mode: 用来规定对该文件的所有者,文件的用户组及系统中其他用户的访问权限,则文件权限为:mode&(~umask) 函数说明: 参数pathname 指向欲打开的文件路径字符串。下列是参数flags 所能使用的旗标: O_RDONLY 以只读方式打开文件 O_WRONLY 以只写方式打开文件 O_RDWR 以可读写方式打开文件。上述三种旗标是互斥的,也就是不可同时使用,但可与下列的旗标利用OR(|)运算符组合。 O_CREAT 若欲打开的文件不存在则自动建立该文件。 O_EXCL 如果O_CREAT也被设置,此指令会去检查文件是否存在。文件若不存在则建立该文件,否则将导致打开文件错误。此外,若O_CREAT与O_EXCL同时设置,并且欲打开的文件为符号连接,则会打开文件失败。 O_NOCTTY 如果欲打开的文件为终端机设备时,则不会将该终端机当成进程控制终端机。 O_TRUNC 若文件存在并且以可写的方式打开时,此旗标会令文件长度清为0,而原来存于该文件的资料也会消失。 O_APPEND 当读写文件时会从文件尾开始移动,也就是所写入的数据会以附加的方式加入到文件后面。 O_NONBLOCK 以不可阻断的方式打开文件,也就是无论有无数据读取或等待,都会立即返回进程之中。 O_NDELAY 同O_NONBLOCK。 O_SYNC 以同步的方式打开文件。 O_NOFOLLOW 如果参数pathname 所指的文件为一符号连接,则会令打开文件失败。 O_DIRECTORY 如果参数pathname 所指的文件并非为一目录,则会令打开文件失败。

03

使用方舟编译器检查Fastjson OOM问题

通过介入编译期间进行安全检查是类似于Facebook infer类的产品,为什么要这么做呢?源代码安全检查工具粗略分为两个大的流派,一个是类似于coverity,需要编译,厂家集成实现了cov-build这样的编译工具;另一个是checkmarx直接分析语法树进行检查,再上层的例如p3c、pmd、sonarcube都是基于字节码、数据流的规范检查,执行编译有助于将代码规范起来,缓解路径不可达问题降低误报,SAST不能避免软件工程的莱斯定理(Rice’s Theorem)在图灵机的应用:我们可以把任意程序看成一个从输入到输出上的部分函数(Partial Function),该函数描述了程序的行为,关于程序行为的任何非平凡属性,都不存在可以检查该属性的通用算法,误报是允许在得不到精确值的时候,给出近似答案,这个答案就是一定比例的误报或者漏报。本文即尝试类似RoboVM、SVF使用LLVM的思路进行数据流和控制流的软件错误检测。扩展知识可以看下北大熊英飞教授的软件分析技术(Software Analysis)公开课件https://xiongyingfei.github.io/SA/2018/main.htm。

03

Linux内核(5.10)-IO全路径-文件系统到磁盘-或远端iscsi/nvmeof协议盘

DAX: 磁盘(disk)的访问模式有三种 BUFFERED、DIRECT、DAX。前面提到的由于page cache存在可以避免耗时的磁盘通信就是BUFFERED访问模式的集中体现;但是如果我要求用户的write请求要实时存储到磁盘里,不能只在内存中更新,那么此时我便需要DIRECT模式;大家可能听说过flash分为两种nand flash和nor flash,nor flash可以像ram一样直接通过地址线和数据线访问,不需要整块整块的刷,对于这种场景我们采用DAX模式。所以file_operations的read_iter和write_iter回调函数首先就需要根据不同的标志判断采用哪种访问模式, kernel在2020年12月的patch中提出了folio的概念,我们可以把folio简单理解为一段连续内存,一个或多个page的集合

01

有赞零售智能硬件体系搭建历程

有赞零售 App 上线至今,为了降低商家硬件迁移成本,同时提高商家硬件采购的选择多样性,陆陆续续对接了市面上 Top 20+ 的智能硬件,包括打印机、电子秤、扫码枪、摄像头、一体机等, 在硬件对接过程中团队投入了大量的人力进行支持,受限于硬件架构不成体系、硬件类目划分不清晰、通信协议多样性、多端重复适配造轮子等因素,导致硬件线上问题较多,且投入的开发成本很高,也影响了商家的正常经营。为了彻底解决这些问题,提高新设备对接效率,并确保硬件交互质量,有赞零售移动团队对硬件体系做了几次重构演进,目前一款新硬件的对接与适配成本已经控制在一到两个工作日内,相较2019年人力投入降低了50%。同时通过不断完善硬件 FAQ 文档,协助商家与硬件支持同学快速定位解决问题,硬件开发同学直接处理的线上问题数量相较2019下半年环比下降55%,技术支持同学对接的硬件问题也环比下降了33%,提效比较明显。

02
领券