首先要介绍一下Linux中input子系统的模型，一图胜千言，所以直接上图。
上图一目了然，我们的键盘驱动就是工作在input子系统的最低层。单纯地从驱动角度讲，我们的工作就是最终调用input_event()这个函数，把扫描到的键值传递给input core层。然后的事情就不是我们考虑的了，这样一来感觉很轻松的样子。
好吧！正式开工了！首先说明一下硬件环境，我用的是友善之臂的tiny210开发板。出厂配置的内核是没有加入矩阵键盘的。不过驱动代码是有的，所以在menuconfig里面配置矩阵键盘。说实话，这工作真的很弱智的样子。为什么呢？因为210处理器上是有一个键盘控制器一样的东西。什么扫描，消抖都是硬件在干。唯一需要改动的地方就是键盘的键值表。默认的驱动里面只用44的键值数据，但是我要用的键盘要88才行。
然后我们分析一下驱动的结构，键盘在210上是作为一个平台设备存在的。那么… 【查看更多】
对于Java自带的对象序列化，我并没有仔细研究过它的实现机制。对于Java默认的序列化机制，它的最大优点就是简单方便。你需要做的仅仅是对需要序列化的POJO增加一句implement Serializable，最多最多再增加一行serialVersionUID。其他的事情就不用我们操心了。那么Java默认的序列化机制是如何实现的呢？答案就是——反射。
Person person = new Person(25, "Tim");
FileOutputStream fos = new FileOutputStream("Person.txt");
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(person);
上面这段代码是典型的默认序列化使用方式。玄机就… 【查看更多】
在TCP/IP协议中，由于传输层并不了解应用层数据的含义，发送端传输层可能会对应用层数据进行拆分或者合并，在接收端也同样如此。由此而产生的问题就是常常会听说的“粘包与拆包”的问题。“粘包拆包”的问题在“短报文”和“一问一答”的场景下其实并不会出现。短报文是指报文长度远小于MSS的情况，应用层的报文在TCP报文中完全可以放下。另一方面，“一问一答”的通信模式可以保证报文会以单一的TCP包发送出去。在这两个条件下都满足时，我们不需要考虑“粘包拆包”问题。
反之，如果这两个条件不同时满足，就很可能会出现“粘包拆包”问题。
粘包拆包的问题的原因大概有以下几个方面：
随着网络安全技术的发展，SSL(Secure Socket Layer)逐渐成为了一种广泛应用的技术。甚至我个人认为，SSL已经成为软件从业人员必须要理解的技术。回想起来，我为了学习SSL技术还是花了不少的时间。可惜应用的少，所以很多知识点都开始淡忘了。前几天，同事们在讨论SSL的问题，我没忍住就参合了进去，大致的讲了一下自己对SSL的一些理解，也讨论了一些相关问题。这些交流也算是简单复习了一下SSL方面的知识吧！期间也发现了自己对相关知识点有些生疏了，所以就准备写点关于SSL的问题。这篇算是个人第一篇关于网络安全的blog了。
关于历史发展的内容，我就不赘述了。还是直接上SSL的通信流程图了，上图展示了完整的SSL通信过程。下面结合上图解释一下SSL的整个流程。
最新评论