There is a device file called /dev/console, whose (major,minor) is (5,1).
When I boot with a serial console, it connects to my UART port as /dev/ttyS0 does.
But when I boot with serial console disabled, the /dev/console seems to connect to elsewhere, where /dev/ttyS0 always connects to the same physical device, namely UART0.
Is there any indication (like something in /proc or /sys) showing such information? I have tried there but found nothing I want.
I am starting to trace the Linux kernel source to clarify their relationships.
Can anyone give me some hints? When, where, how and what to determine the physical device to which /dev/console connects?
EDIT: The latest finding is that:
the /dev/console is configured by console= of the kernel parameters, which in turn is used by getty to open stdin/stdout/stderr. If no console= is specified, /dev/null is opened as stdin/stdout/stderr. But I am not sure they are exactly the same with /dev/console, which implies /dev/console can have its I/O connecting to different physical devices.
The /dev/console can be read if a USB HID keyboard is plugged and the console= is not configured as UART. Therefore /dev/console == /dev/null seems to make little sense.
Need more investigations.
I think /sys/devices/virtual/tty/console/active is what you're looking for.
From http://man7.org/linux/man-pages/man4/console.4.html :
"The current console is also addressed by
/dev/console or /dev/tty0, the character device with major number 4
and minor number 0."
I hope that was what you were looking for.
Related
First allow me to say that I don't have any experience developing drivers for OSX, nor drivers for Windows. So, there are a lot of things that I don't understand about how drivers work; I'm sure it'll be evident in my question.
I have a modem that is able to open and close TCP/UDP sockets using AT commands. I would like to create some kind of program (kernel extension? driver?) that implements a network driver, converting the network interface calls into AT command serial messages.
That's the basic jist of it. I'm essentially asking if anybody can point me in the right direction / give me a high level overview of how they would approach it and what Apple guides to focus on.
The XNU networking stack -- like most network stacks -- expects network devices to send and receive IP packets directly. It isn't tooled to work with network devices that handle part of the network stack (like TCP or UDP) internally -- it won't be possible to implement a network driver which uses this device.
You might have more luck exposing this device as a SOCKS proxy. You will need to write a userspace daemon which listens on a TCP port on localhost (on the computer) and relays traffic to the serial device; once that's done, you can set the computer to use that device as a SOCKS proxy in the Networking control panel.
(As an aside: most devices that implement this type of interface have a very low limit on the number of open sockets -- often fewer than 10. They're unlikely to be able to handle the network load generated by a desktop OS.)
I just want to know how to find a usb device is connected to USB3.0 or USB2.0 port in window . I am using c++ and win32 API. please let me know your thoughts.
Based on how your question is phrased, I assume that you know when a device is connected, and need to know if the port it's connected is capable of USB 3.0 speeds.
Take a look at the USB_NODE_CONNECTION_INFORMATION_EX structure, and specifically the field Speed in it, which could correspond to a value defined in the enum USB_DEVICE_SPEED. For USB 3.0, the value of Speed would be UsbSuperSpeed.
The documentation page says that you could use IOCTL_USB_GET_NODE_CONNECTION_INFORMATION_EX request to obtain information about the connection associated with the indicated USB port.
You may also find the following remarks from the documentation helpful:
If there is no device connected, IOCTL_USB_GET_NODE_CONNECTION_INFORMATION_EX just returns information about the port.
If a device is connected to the port IOCTL_USB_GET_NODE_CONNECTION_INFORMATION_EX returns information about both the port and the connected device.
The USB_NODE_CONNECTION_INFORMATION_EX structure is an extended version of USB_NODE_CONNECTION_INFORMATION. The two structures are identical, except for one member. In the extended structure, the Speed member indicates the device speed.
I'd also encourage you to single-step through the usbview project which is part of the windows driver samples available in Github.
Is this kind of link aggregation even possible?
On a Windows machine, there are several 3rd-party applications which make use of bonding and load balancing multiple network interfaces for increased throughput, such as Connectify Dispatcher, for example. Would it be possible to develop such an app for OSX? Is there already any 3rd-party software which does this on OSX? The closest thing I could find was IPNetRouterX, which I've failed to use for bonding USB and WiFi network interfaces.
I have also tried the following line in OSX's terminal:
sudo networksetup -createBond bond0 en1 en3
...where en1 is my WiFi interface and en3 is my USB network interface, which simply results in:
** Error: The parameters were not valid.
Likely, there would need to be some sort of Layer 2 "magic glue" to make this in any way a possibility... but primarily being a Windows programmer, I'm not sure if Apple would enjoy allowing that level of programming access, considering how proprietary they like to be...
Any idea what can be done here?
There are options to networksetup to tell you whether the OS can bond a particular port or not. To do so, you need to hand it a "hardware port", which you can find by using:
networksetup -listallhardwareports
Each of those, in turn, can be queried using
networksetup -isbondsupported <HW Port Name>
Bonded networks are set up using the networksetup port name, not the kernel interface name, so if you were to bond two ethernet networks, you would do so like this:
networksetup -createBond myBondedNet 'Ethernet 1' 'Ethernet 2'
Querying the ports on my 2009 MacPro running 10.9, I find only the hardware ethernet ports to respond YES to the -isbondsupported inquiry.
Note that I didn't have to have the port operational in order for -isbondsupported to return YES, so in my case both of my ethernets responded YES even though only one is currently connected.
gaige thanks for your technical answer but RectangleEquals is not asking how to do Link Aggregation through terminal but
IF Link Aggregation can work for USB, WIFI, or other type of internet connections.
The answer is NO.
Apple didn't created Link Aggregation. It's a separated feature Unix had. Therefore Apple has zero idea how to improve it - nor does it want to spent resource to figure it out because it is not a common enough demand. Even if it wants to give you the feature it will not provide in a regular version of OS X but will provide in a server version and charge you for it.
And there are developers who can do it, by writing a lot of codes - so no free version of such application exist. You can try Connectify Switchboard for OS X.
I found that there is actually no decent way of accomplishing this, thanks to the way that networking is handled via separate interfaces. Although it would be possible to use two separate interfaces to connect to the same remote data source, it would require kernel-level programming skills to get these two interfaces working in unison... And the packets returned through each separate interface would be handled VERY differently, and the network packets would be far too out of sync with each other... So even then, if you were to create some sort of magic bridge to handle all of these situations and somehow use two separate interfaces to pull the same synchronous data, it would end up being (best case scenario) the exact same speed -- but likely SLOWER -- than with just one network interface. Far too much hassle for almost zero benefit.
I'm trying to create serial communication in NetBSD. This
communication will connect the computer with a controller via RS-485.
The problem is that I don't know if it necessary some configuration or driver to do it.
Specifically, the communication will be through the RS-485 port. I've tried to use /dev/tty01, but there are no pulses in serial output.
Are there some configurations , drivers or codes necessary to open, send and receive serial data in NetBSD?
I didn't have sucess until now.
Thanks
Nothing special needed.
If your serial is a real serial, then you could connect via:
# cu -l /dev/tty00
if your serial is a serial over USB then:
# cu -l /dev/ttyU0
However in both cases you have to be root, or change permissions on the device.
If the output is not visible, then adjust the speed with -s switch.
I need to create a Cocoa app that will create a virtual serial port available to other apps, meaning registered in the IO Kit Registry.
Gist of the app:
Create a virtual serial port (listed in /dev and registered with the IOKit Registry)
Initiate a tcp connection out to another computer
Proxy everything received on the virtual serial port out to the
network and vice versa.
This app will be used by third party apps that talk to serial ports on the computer, allowing for the particular serial device to be located across the network. The Cocoa and network part is no problem, I've written several apps that talk over the network. My hangup is the serial port.
I've done the test with socat/netcat/minicom to verify that it all works to proxy pty/tty traffic over the network but the tty I use doesn't show up as usable by random applications because it's not registered in the IO Kit Registry.
While I can use a pty/tty master/slave for the communication, I need this slave tty to show up to Mac applications. What would be very handy is a way to register a tty in the IO Kit Registry.
Do I really need to create a custom IOKit kext driver that gets registered at Cocoa app runtime? If so, I have a big learning curve ahead of me. Where should I start reading? Or, can I use IOKit to create a virtual serial port and register it as a usable serial port for applications without having to load any kernel extensions?
Thank you for any help you can provide,
Stateful
First of all, have you checked if you can borrow a solution from this app? It's not obvious from the website if they've managed to get their virtual serial ports fully integrated into the system.
If there is a way to do it from user space, I'm not aware of it. The user-space IOKit API generally doesn't let you create class instances, let alone new device driver classes. Maybe you can somehow otherwise persuade the Cocoa libraries to find it despite not being registered in the kernel.
I don't know if you could get away with creating a "dummy" serial port in the kernel and then move your tty into its place in /dev from your userspace daemon. Maybe that's an option.
In case you do have to do it all in the kernel:
The virtual driver itself shouldn't be too much work, at least, though it will require some time to get up to speed with kernel dev. Unfortunately, the documentation is pretty thin for serial port drivers - the key is subclassing the IOSerialDriverSync abstract class. Just about the only description I've seen is in Ole Henry Halvorsen's OSX and iOS Kernel Programming book. It also has a fragment of an example for the reading & writing operations. (disclosure: I was one of the tech reviewers for this book; I don't receive any incentives for recommending it - in this case it's literally the only documentation I know of) You can find the source for a complete serial port driver in Apple's USBCDC driver, AppleUSBCDCDMM is the class that actually represents the serial port node.
It's relatively straightforward to open a so-called "kernel control" socket in the kernel, the individual APIs are documented here; from user space you use the normal BSD socket send/recv APIs. (this is also described in the aforementioned book) Your daemon can then connect to that, and all you'd need to do is push the data between the socket and the virtual serial port device. You'll need to handle disconnect events and such correctly of course.
Still, I think this is achievable as a first kernel project for an experienced C programmer (with some C++).
I hope that helps!