• CHANGELOG, ЛИЦЕНЗИИ, READMEи АПГРЕЙДА текстовых документов
• демо папку
• рамках папку
• Требования папку

Вы должны прочитать README и ЛИЦЕНЗИИ документы, конечно, но папки являются наиболее важными здесь. Демо папка содержит четыре веб-приложения, написанные с использованием Yii. Они большое за то, рабочий код, как вы пытаетесь написать свой. Рамках папку это то, что требуется какой-либо веб-сайт использованием Yii. Требования папка-то простое и блестящий …

Я также предполагаю, что вы уже знаете, что в корневом каталоге веб на вашем компьютере или сервере: это папка, где ваш URL указывает.Иными словами, когда вы идете в http://localhost или http://www.example.com в веб-браузере, она хватает документов из корневой папки сайта.Идущий с конвенциями в Yii, я называю это WebRoot. Создать новую папку в WebRoot называется юйи скопируйте рамки и требования папки существуют. Затем перейдите к yourURL/ юй / требования в веб-браузере (например, http://localhost/yii/requirements). Вы должны увидеть отчет в том, является ли вашей установки соответствует минимальным требованиям.

Если предположить, что установка прошла все требования, вы хорошо идти дальше. Заметим, что вам не обязательно каждое расширение: вы просто действительно нужно Yii Рамочной требованиям, PDO, а также расширение PDO для базы данных вы будете использовать. (Если вы не знакомы с ним, ПДО уровня абстракции базы данных, что делает веб-сайты базы данных агностиком.)

В моем следующем посте я покажу вам, как использовать командную строку Yii инструменты для создания первого веб-приложения. Это очень сладкие вещи, и ближе всего к Ruby On Rails, что я видел (который я считаю очень хорошо). Последующие сообщения будут объяснить MVC, и выделить конкретные советы и рекомендации я обнаружил, при разработке мой Yii-сайтов.

No related posts.

The linux kernel has a facility called “usbmon” which can be used to sniff the USB bus. It’s been in there for ages, and the output is really easy to collect, even from the command line shell. Simply mount debugfs and insmod the usbmon module:

mount -t debugfs none_debugs /sys/kernel/debug
modprobe usbmon

Then you can just cat USB traffic like this:

cat /sys/kernel/debug/usbmon/1u

It all comes out in an ASCII dump format which is easily parsed. Every USB bus also has a device file where you can sniff the raw packets straight off the wire. More info in the usbmon documentation.

But while it’s all easily parsed if you need it, there aren’t really any tools around that do it for you. That is… except for libpcap. Libpcap is the power behind the throne of the venerable tcpdump tool. Tcpdump is not much more than a command line parser and pretty-printer of various network protocols. The heavy duty lifting is done by libpcap, not least by providing a cross-platform API for sniffing devices, something that is otherwise non-standard and different on every platform. It’s great, I’ve used it before (in capstats) and it’s very easy to use.

Libpcap on linux supports usbmon sniffing, which means you can use tcpdump to sniff a USB port and write this to a capture file. But best of all: wireshark, the all-singing all-dancing network analyzer that uses tcpdump capture files, has USB support as well.
So this is the result:

The screenshot shows a filter applied to only see device 18 on the sniffed USB bus. That’s an arduino, i.e. an FTDI USB-serial chip. The FTDI chips send status updates to the USB host system every 16ms (!). The status update consists of a two-byte message (described here). This is actually present in every packet coming in from the FTDI chip; status updates just don’t have any other data. So for a clean sniffing session from the arduino, we want to filter out any packets that are < 3 bytes in length.

The end result is serial data which the arduino sent to the host system. The screenshot shows a session on my arduino shell, arsh. This is great stuff — wireshark includes a massive amount of analysis tools and lots of options for filtering and otherwise massaging your captured data.

You need relatively recent versions of libpcap, tcpdump and wireshark for this. I compiled all three of these out of their respective repositories (easy compile all). On my ubuntu system, the libpcap version was particularly old. Tcpdump doesn’t have a pretty-printer for USB data yet, so you can only dump to a capture file for processing by wireshark.

No related posts.

I frequently get asked how I managed to end up working on the Fedora kernel for living by people hoping to one day get into kernel hacking themselves. One of the most common things I hear is that the kernel is so big, how could anyone possibly understand it all? Truth is, there are very few people that really understand the whole kernel. The majority of the ‘big name’ kernel hackers got where they are today by specialising in one thing, and branching out. There are exceptions to this of course, with a number of people like Andrew Morton, Alan Cox, and Linus who are ‘all rounders’, who have hacked on close to everything in the tree at some point. Whilst the kernel could always use more people like these superheros, there is nothing wrong with becoming a specialist in one area.

One thing that both the all-rounders, and specialists have in common however, is an understanding of the common kernel APIs. Things like ‘how to allocate/free memory’ ‘how to create proc/sysfs files’ Most ‘how do ..’ questions can be answered by taking a look at how other parts of the kernel are already doing something similar. With enough experience of use of the common APIs, higher level concepts are learned such as ‘how to create userspace interfaces that don’t suck’.

There is no fast path to learning kernel hacking. It comes down to a big time investment on your part to read (and understand) code, learn from mistakes you make (and you will make them!), and above all, realising that in the end, it’s just code. There may some additional restrictions for kernel hacking that you could get away with in userspace, but once you’ve grasped the basics, a lot of it just follows.

The basics:

• Make sure you understand how to compile and install a kernel before going any further.
• A sound knowledge of C is essential. If you’re still struggling with pointer arithmetic and such concepts, stick with hacking stuff in userspace until you understand more. A crash in userspace caused by your misunderstanding is a lot easier to debug, understand and learn from than one in the kernel which just causes your machine to lock up or reboot itself.

Must-read material:

• kernelnewbies is a great resource for those starting out. It contains a lot of examples, and pointers.
• Some good books on kernel hacking include Linux Kernel Development (2nd ed.) by Robert Love, Linux Kernel in a nutshell by GregKH and the 3rd edition of Linux Device Drivers by Jonathan Corbet.
• Jonathan also writes a really good concise summary of the past week of kernel development each week at lwn.net. It’s well worth reading, even if you follow linux-kernel, as the rephrasing and explanations are sometimes a lot better in summaries than reading through a 200 email thread.
• The Linux kernel comes with a Documentation/ directory which contains a number of really useful documents worth spending some time reading.
• Finally the code itself. Find something that interests you, find out where in the kernel that is handled, and just start reading.

Useful tools:

• grep –r is invaluable.
• You’re going to be building and rebuilding a lot. So install ‘ccache’. Most distros have it packaged so that it automatically sets itself up after installing. You may also want to look at ‘distcc’ if you’ve a lot of potential build-cluster candidate machines local to you.
• Regardless of whether you’re an emacs or vi person, ‘ctags’ are invaluable for navigating your way around the source tree. ‘make tags’ in the toplevel of the kernel tree will generate an index. You can learn how to navigate with them in the man pages of your favorite editor. (In vi, ctrl-] over a symbol jumps to that function, ctrl-t takes you back. :ts will bring up a list of alternatives if there are >1 hit for that function name. You can alsovim –t functionnamefrom the command line)
• Some other folks find cscope really useful for the same purpose. ‘make cscope’ generates the index, running ‘cscope’ gets you an interface to jump to where functions are used/defined etc.

“I don’t know what to hack on!“
A great way of putting your newly learned skills to good use is to take a look at the open bugsin the kernel bug tracker, find something, and try to help fix it. Whilst many driver bugs need the hardware to really debug/test a solution, a lot of problems can still be found purely by code inspection. There are no shortage of new bugs being filed all the time, and bug-fixing is a great way to learn about many different areas of the kernel and how they interact. The days of driver authors getting all the chicks and fast cars ended some years ago. Fixing bugs, that’s where the fun is at.

“I really just don’t get it“
Not everyone gets to be a spaceman, rockstar, or kernel hacker when they grow up. It’s fine. Really. There are still a lot of things you can do to help out Linux.

• Testing. Even if hacking code isn’t your thing, building and testing the latest snapshots of Linus’ tree, or Andrew’s –mm tree if you’re feeling really adventurous is always useful. If it breaks, great! You get to contribute something. A bug report to the linux-kernel list.
• related to testing — write test tools. A new syscall got added? Great, write an application to use it in every way imaginable. Complain loudly when it breaks. Some of the simplest test tools have been the most useful to us. Filesystem stress tools like fsx have been so useful they become a ‘must-use’ tool for filesystem developers.
• Hacking userspace isn’t ‘uncool’. There are a *lot* of things still in need of a lot of love in userspace. Find something that bugs you, and fix it. Can’t fix it? Get involved with the people who wrote it, maybe they’ll give you pointers. Some of the larger projects like xorg are really in need of hackers (FWIW, if you have an inclination to work on hardware related code like drivers, X may be a better starting place than the kernel for reasons such as ease of debugging).
• Triage work. The kernel bugzilla is swamped with bugs. A lot of them really old ones that may even be fixed by now. No-one has the time to regularly go through them all, looking for patches that never got applied upstream, closing duplicates, pinging reporters etc. Get involved!
• Documentation. If along your journey you find something particularly hard to understand, and you found no documentation on it, here’s your chance to be a documentation-writing-superhero! Kernel hackers hate writing documentation for some strange reason.

“What about janitor tasks?“
Whilst the janitor project has some useful information, patches that do nothing but clean up code to comply with style guidelines and other such trivial patches aren’t really a great way to learn. No-one ever learned any skills by changing indentation of a function. Learn some of the ‘rules’ proposed there, but instead of focusing on them as ‘something to do’, use those rules whilst doing something more useful.

I add to this page periodically when I get new questions from people, or new ideas that I think people could learn from. If you have questions about beginning Linux kernel hacking, feel free to drop me an email, and I’ll try to point you in the right direction. I don’t really have the time to help you debug why your code is crashing, but for higher level questions, even if I can’t help you out, I probably know someone who can.

No related posts.

Here we will post different interesting things about linux/unix kernel hacking and etc.

No related posts.